diff options
Diffstat (limited to 'hurd/ng')
25 files changed, 109 insertions, 54 deletions
diff --git a/hurd/ng/cancellationforwarding.mdwn b/hurd/ng/cancellationforwarding.mdwn index 1b7776f2..6b2977c7 100644 --- a/hurd/ng/cancellationforwarding.mdwn +++ b/hurd/ng/cancellationforwarding.mdwn @@ -2,18 +2,18 @@ ## <a name="Rationale"> Rationale </a> -When a request to one or more servers is needed from a server to process a request from it's client, and the client cancels it's request, there will be at least temporary resource leakage in the chain of servers. +When a request to a chain of one or more servers is needed from a server to process a request from its client, and the client cancels its request, there will be at least temporary resource leakage in the chain of servers. -If the last server in the chain completes processing and gives a response to it's client, there will be unnecessary CPU and memory usage from all the servers. And if one of the servers never completes, there will be permanent memory leakage. +If the last server in the chain completes processing and gives a response to its client, there will be unnecessary CPU and memory usage from all the servers. And if one of the servers never completes, there will be permanent memory leakage. -Timeouts are a way to avoid the permament memory leakage, at the cost of rendering the whole communication impossible above some system load. They also only bring the duration of the memory leakage from infinite to some time. +Timeouts are a way to avoid the permament memory leakage, at the cost of rendering the whole communication impossible above some system load, hence opening a denial of service possibility. They also only bring the duration of the memory leakage from an infinite to an arbitrary finite time that may have no relation with the operations of the servers. -Cancellation forwarding is a mechanism that can be used to propagate, without additional overt communication, the information that initial request has been cancelled. +Cancellation forwarding is a mechanism that can be used to propagate, without additional overt communication, the information that initial request has been cancelled. It also bring the duration of the memory leakage to a finite time, but each server in the chain is able to use the protocol at key points of its operations (like before a costly operation), and because the protocol will not produce false positive results, it can be used at an arbitrary high frequency. The only tradeoff is between leakage time and checking overhead. ## <a name="Protocol"> Protocol </a> -* Each client that want to forward cancellation to it's server increment the protected payload of the FCRB for which a sender's capability has been given to the server, thus invalidating the capability. -* Each server that wants to notice cancellation forwarding will set up a watchdog, and ask the kernel to send heartbeats. At each heartbeat, the watchdog check that the reply capability to the FCRB of the client is not invalid, with a Discrim capability. +* Each client that want to forward cancellation to its server increment the protected payload of the FCRB for which a sender's capability has been given to the server, thus invalidating the capability. +* Each server that wants to notice cancellation forwarding will either set up a watchdog, and ask the kernel to send heartbeats, or decide for deterministic check points in its operations. At each heartbeat or check point, the server checks that the reply capability to the FCRB of the client is not invalid, with a Discrim capability. ## <a name="Example"> Example </a> @@ -33,16 +33,16 @@ Notation: ( T successfully treat the request, now goes completion ) * T invokes c2 -* S reads the answer, and increment the PP of the FCRB->S +* S reads the answer, and increments the PP of the FCRB->S * S invokes c1 -* C reads the answer, and increment the PP of the FCRB->C +* C reads the answer, and increments the PP of the FCRB->C ### <a name="Uncomplete_operation_"> Uncomplete operation: </a> * C invokes a cap to S, giving S a cap c1 to a FCRB->C -* S sets up a watchdog that check that discrim.classify(c1) != clVoid +* S sets up a watchdog that checks that discrim.classify(c1) != clVoid * S invokes a cap to T, giving T a cap c2 to a FCRB->S -* T sets up a watchdog that check that discrim.classify(c2) != clVoid +* T sets up a watchdog that checks that discrim.classify(c2) != clVoid ( for any reason, C decides to stop, now goes cancellation ) @@ -53,4 +53,4 @@ Notation: ---- --- [[Main/NowhereMan]] - 28 Apr 2006 +-- [[Main/NowhereMan]] — originally designed in April 2006 diff --git a/hurd/ng/choiceofmicrokernel.mdwn b/hurd/ng/choiceofmicrokernel.mdwn deleted file mode 100644 index 20ee6f05..00000000 --- a/hurd/ng/choiceofmicrokernel.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -TBD - -* [[MicrokernelL4]] -* [[MicrokernelCoyotos]] diff --git a/hurd/ng/copyvsrevocablecopyvsmap.mdwn b/hurd/ng/copyvsrevocablecopyvsmap.mdwn index 9c99c0a1..0cda7e24 100644 --- a/hurd/ng/copyvsrevocablecopyvsmap.mdwn +++ b/hurd/ng/copyvsrevocablecopyvsmap.mdwn @@ -3,4 +3,4 @@ TBD, see: * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00274.html> * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00023.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/designgoals.mdwn b/hurd/ng/designgoals.mdwn index 5dbd7018..d04007c2 100644 --- a/hurd/ng/designgoals.mdwn +++ b/hurd/ng/designgoals.mdwn @@ -2,7 +2,9 @@ ## <a name="The_Position_Paper"> The Position Paper </a> -_Improving Usability via Access Decomposition and Policy Refinement_ tries to capture technical objectives. As has been stated by Neal in [2], these are a number of scenarios we are interested in addressing: +The [[position_paper]] tries to capture technical objectives. As has been +stated by Neal in [2], these are a number of scenarios we are interested in +addressing: * security: programs are not users; they should be constrained according to the user's intents * resource management @@ -30,7 +32,7 @@ Extensibility has often been a strong argument to support the multiserver approa However, I do believe there are benefits in multiserver environments you cannot get in a monolithic one, namely enhanced security and stability through protection boundaries. Also, whilst wanting to become adopted as general purpose OS, ngHurd still strives to allow for research also, so even according to the above-referenced paper extensibility is to be one of its goals. -Therefore, I'd want to propose to weaken the impact of extensibility on the design, by lowering it to the category "Regular Goals". -- [[Main/TomBachmann]] - 13 Dec 2006 +Therefore, I'd want to propose to weaken the impact of extensibility on the design, by lowering it to the category "Regular Goals". -- [[TomBachmann]] - 13 Dec 2006 ## <a name="Regular_Goals"> Regular Goals </a> @@ -49,5 +51,3 @@ Therefore, I'd want to propose to weaken the impact of extensibility on the desi * [1] <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00037.html> * [2] <http://lists.gnu.org/archive/html/l4-hurd/2007-01/msg00122.html> - --- [[Main/TomBachmann]] - 29 Apr 2006 diff --git a/hurd/ng/discussion.mdwn b/hurd/ng/discussion.mdwn new file mode 100644 index 00000000..d4632bd5 --- /dev/null +++ b/hurd/ng/discussion.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +To go beyond research project Hurd have to support thousands of various programs running on GNU/Linux nowadays. +It looks like ExoKernel approach http://pdos.csail.mit.edu/exo.html might be useful here. +Does somebody tried to look into something like Hurd exokernel + liblinux? diff --git a/hurd/ng/firstclassreceivebuffer.mdwn b/hurd/ng/firstclassreceivebuffer.mdwn index c3cc3142..30087bf2 100644 --- a/hurd/ng/firstclassreceivebuffer.mdwn +++ b/hurd/ng/firstclassreceivebuffer.mdwn @@ -1,3 +1,3 @@ TBD, see e.g. <http://coyotos.org/docs/ukernel/spec.html> and <http://www.coyotos.org/pipermail/coyotos-dev/2006-January/000391.html> --- [[Main/TomBachmann]] - 31 Aug 2006 +-- [[TomBachmann]] - 31 Aug 2006 diff --git a/hurd/ng/howmuchconfinementdowewant.mdwn b/hurd/ng/howmuchconfinementdowewant.mdwn index 663e5bbb..1963ae73 100644 --- a/hurd/ng/howmuchconfinementdowewant.mdwn +++ b/hurd/ng/howmuchconfinementdowewant.mdwn @@ -90,4 +90,4 @@ Marcus started a challenge [5] to find a use case for non-trivial confinement th * [4] <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00012.html> * [5] <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00407.html> --- [[Main/TomBachmann]] - 01 May 2006 +-- [[TomBachmann]] - 01 May 2006 diff --git a/hurd/ng/hurdishapplicationsforpersistence.mdwn b/hurd/ng/hurdishapplicationsforpersistence.mdwn index 12861ecb..d785694b 100644 --- a/hurd/ng/hurdishapplicationsforpersistence.mdwn +++ b/hurd/ng/hurdishapplicationsforpersistence.mdwn @@ -2,4 +2,4 @@ TBD, see: * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html>; summary: passive translators started by the filesystem cannot be done right and persistence makes passive translators unnecessary --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/limitations_of_the_original_hurd_design.mdwn b/hurd/ng/limitations_of_the_original_hurd_design.mdwn new file mode 100644 index 00000000..96d8912b --- /dev/null +++ b/hurd/ng/limitations_of_the_original_hurd_design.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + + * [[Critique]] diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn deleted file mode 100644 index 40fd6e9d..00000000 --- a/hurd/ng/microkernelcoyotos.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -# <a name="The_Coyotos_microkernel"> The Coyotos microkernel </a> - -[Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). It's main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well and to completely formally verify both the kernel and critical system components by writing them in a new language called bitc. - -Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC whith asynchronous syscalls). - -TODO: explain these terms and (more important) their consequences on system design. - -The coyotos microkernel specification can be found [here](http://www.coyotos.org/docs/ukernel/spec.html) diff --git a/hurd/ng/part2systemstructure.mdwn b/hurd/ng/part2systemstructure.mdwn index 4ce8026f..0f94ff2a 100644 --- a/hurd/ng/part2systemstructure.mdwn +++ b/hurd/ng/part2systemstructure.mdwn @@ -38,7 +38,12 @@ It is clear from this description that the child's existance is completely deter ## <a name="Canonical_Process_Destruction"> Canonical Process Destruction </a> -Process destruction can be done either cooperatively, or forcibly. The difference corresponds approximately to the difference between SIGTERM and SIGKILL in Unix. To destroy a process cooperatively, a request message is sent to a special capability implemented by the child process. The child can then begin to tear down the program, and at some time send a request back to the parent process to ask for forced process destruction. +Process destruction can be done either cooperatively, or forcibly. The +difference corresponds approximately to the difference between SIGTERM and +SIGKILL in [[Unix]]. To destroy a process cooperatively, a request message is +sent to a special capability implemented by the child process. The child can +then begin to tear down the program, and at some time send a request back to +the parent process to ask for forced process destruction. Forced process destruction can be done by the parent process without any cooperation by the child process. The parent process simply destroys the primary container of the child (this means that the parent process should retain the primary container capability). @@ -84,7 +89,13 @@ I will now describe some common applications that need to be supported, and how ## <a name="System_Services"> System Services </a> -Unix-style suid applications have been proposed as one application for alternative process construction mechanisms. However, suid applications in Unix are, from the perspective of the parent, not confined, only isolated. Thus, they are readily replaced by a system service that is created by the system software, and that runs as a sibling to any user process. Only the ability to invoke the system service needs to be given to the user, not the ability to instantiate it. +[[Unix]]-style suid applications have been proposed as one application for +alternative process construction mechanisms. However, suid applications in +Unix are, from the perspective of the parent, not confined, only isolated. +Thus, they are readily replaced by a system service that is created by the +system software, and that runs as a sibling to any user process. Only the +ability to invoke the system service needs to be given to the user, not the +ability to instantiate it. In fact, no gain can derived from letting the user instantiate system services. In Unix, system services run on durable resources, which the user can not revoke. Thus, the system service needs to acquire its resources from a container that is not derived from the user's primary container. diff --git a/hurd/ng/pathmax.mdwn b/hurd/ng/pathmax.mdwn index 1c792937..1ea337e9 100644 --- a/hurd/ng/pathmax.mdwn +++ b/hurd/ng/pathmax.mdwn @@ -1,3 +1,3 @@ TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00038.html> and [Vulnerabilities in Synchronous IPC Designs](http://citeseer.ist.psu.edu/shapiro03vulnerabilities.html) --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/permissionbits.mdwn b/hurd/ng/permissionbits.mdwn index 1e1493df..eac00057 100644 --- a/hurd/ng/permissionbits.mdwn +++ b/hurd/ng/permissionbits.mdwn @@ -1,3 +1,3 @@ TBD, see: <http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00231.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/position_paper.mdwn b/hurd/ng/position_paper.mdwn new file mode 100644 index 00000000..abc781da --- /dev/null +++ b/hurd/ng/position_paper.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +Neal Walfield and Marcus Brinkmann wrote a paper titled [*Improving Usability +via Access Decomposition and Policy +Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) +where they give an overview about how a future, subsequent system may be +architected. This is sometimes referred to as *the position paper*. diff --git a/hurd/ng/setuidvsconstructor.mdwn b/hurd/ng/setuidvsconstructor.mdwn index 44c5f7fa..87cce8df 100644 --- a/hurd/ng/setuidvsconstructor.mdwn +++ b/hurd/ng/setuidvsconstructor.mdwn @@ -3,4 +3,4 @@ TBD, see e.g.: * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00167.html> * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00203.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/sharedlibraries.mdwn b/hurd/ng/sharedlibraries.mdwn index 01b85df8..d4969420 100644 --- a/hurd/ng/sharedlibraries.mdwn +++ b/hurd/ng/sharedlibraries.mdwn @@ -1,3 +1,3 @@ TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2005-12/msg00034.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/systemstructure.mdwn b/hurd/ng/systemstructure.mdwn index 8a9bdbe8..ef069edd 100644 --- a/hurd/ng/systemstructure.mdwn +++ b/hurd/ng/systemstructure.mdwn @@ -1,3 +1,3 @@ -TBD, see: <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00324.html> (thread). Also, note that this is derived from [[Philosophy]]. See the interface spec and the position paper as well. - --- [[Main/TomBachmann]] - 31 Aug 2006 +TBD, see: <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00324.html> +(thread). Also, note that this is derived from [[Philosophy]]. See the +interface spec and the [[position_paper]] as well. diff --git a/hurd/ng/thepolycastinterface.mdwn b/hurd/ng/thepolycastinterface.mdwn index 5d1fb8dc..702364cf 100644 --- a/hurd/ng/thepolycastinterface.mdwn +++ b/hurd/ng/thepolycastinterface.mdwn @@ -49,4 +49,4 @@ see also: * <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00002.html> * <http://lists.gnu.org/archive/html/l4-hurd/2006-02/msg00003.html> --- [[Main/TomBachmann]] - 30 Apr 2006 +-- [[TomBachmann]] - 30 Apr 2006 diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 4d221a8e..949895e7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which # <a name="Trivial_Confinement"> Trivial Confinement </a> -For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps: +For trivial confinement, there is a [[system call]] to create a process from +some memory pages. P performs the following steps: * Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P. -* Perform the system call on that memory. The result is a capability to C. +* Perform the [[system call]] on that memory. The result is a capability to C. * Send A to C using the returned capability. Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to. @@ -32,7 +33,16 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # <a name="POSIX_Fork"> </a> POSIX Fork -POSIX fork, or rather fork+exec, is how things are done on many current systems. It may be insightful to see it included in the comparison, especially for people who are new to the subject. There are two system calls, fork and exec. Fork will create a clone of the current process, including all the capabilities (that is, file descriptors) of the parent (except the ones which have explicitly been excluded). Exec is a system call which really goes to the filesystem, not the kernel (although on systems which use it, the filesystem usually resides in the kernel), and asks it to spawn a new process from the contents of a certain path in place of the caller. This passes all capabilities to the new process. The procedure is: +POSIX fork, or rather fork+exec, is how things are done on many current +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork +and exec. Fork will create a clone of the current process, including all the +capabilities (that is, [[unix/file_descriptor]]s) of the parent (except the +ones which have explicitly been excluded). Exec is a [[system call]] which +really goes to the filesystem, not the kernel (although on systems which use +it, the filesystem usually resides in the kernel), and asks it to spawn a new +process from the contents of a certain path in place of the caller. This +passes all capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -52,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is a The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should. -The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other. +The only reason for continuing to use fork+exec would be that it is what +existing programs do. However, they break anyway if they need to specify which +[[unix/file_descriptor]]s to pass. So they need to be adapted. Therefore, it's +better to make the usual spawning method the primitive one, and emulate the +other. # <a name="Trivial_Confinement_vs_Construct"> Trivial Confinement vs Constructor </a> @@ -67,7 +81,7 @@ Except for the control, there is really only one other difference, and that's ad What it doesn't do is protect the code image against bugs in P. In the constructor the trusted and well-tested constructor code is handling the image, for trivial confinement the (very possibly) buggy program P. In particular, when starting a program from a file system, with trivial confinement the operation is: * Ask the file system for the code, receive a capability to a space bank with a copy (on write) of it. -* Make the system call to turn it into a program. +* Make the [[system call]] to turn it into a program. Now this isn't much more complicated than the constructor which does: @@ -75,4 +89,4 @@ Now this isn't much more complicated than the constructor which does: Therefore I am not so convinced that we want a constructor. It gets in the way of debugging, for example, and it doesn't really give any gain. --- [[Main/BasWijnen]] - 13 Jun 2006 +-- [[BasWijnen]] - 13 Jun 2006 diff --git a/hurd/ng/usecaseprivatekeys.mdwn b/hurd/ng/usecaseprivatekeys.mdwn index 612a8f25..3cb65af2 100644 --- a/hurd/ng/usecaseprivatekeys.mdwn +++ b/hurd/ng/usecaseprivatekeys.mdwn @@ -1,6 +1,10 @@ _Private Keys_ as used by SSH servers, clients and generally by any cryptographic software need to be stored and manipulated securely. These may get replaced with smartcards soon, but in the mean time it appears to be an interesting use case. -All Unix systems that I am aware of do not allow secrets to be protected in a manner that I would feel is appropiate. A users compromised web browser could either read your private key file or talk to the very popular ssh-agent program and get your secrets out (not sure how popular distributions are configured, but it can be done). +All [[Unix]] systems that I am aware of do not allow secrets to be protected in +a manner that I would feel is appropiate. A users compromised web browser +could either read your private key file or talk to the very popular ssh-agent +program and get your secrets out (not sure how popular distributions are +configured, but it can be done). The requirements so far are: diff --git a/hurd/ng/usecaseuserfilesystem.mdwn b/hurd/ng/usecaseuserfilesystem.mdwn index 6dce5670..4e4fdf35 100644 --- a/hurd/ng/usecaseuserfilesystem.mdwn +++ b/hurd/ng/usecaseuserfilesystem.mdwn @@ -3,7 +3,7 @@ These appear as _translators_ in the current Hurd and something similar needs to appear in the next hurd. * The user should be able to dynamically add and remove translators -* For some reason it seems appropiate to have seperate namespaces (VFS's) for each user (this is quite a departure from Unix. [[SamMason]]) +* For some reason it seems appropiate to have seperate namespaces (VFS's) for each user (this is quite a departure from [[Unix]]. [[SamMason]]) * translators can be used to expose the structure of an archive file * translators can be provide access to remote file systems diff --git a/hurd/ng/whatisacapability.mdwn b/hurd/ng/whatisacapability.mdwn index a4ed5ed8..f3a42dd8 100644 --- a/hurd/ng/whatisacapability.mdwn +++ b/hurd/ng/whatisacapability.mdwn @@ -1,3 +1,3 @@ TBD, see e.g.: <http://www.eros-os.org/essays/capintro.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 diff --git a/hurd/ng/whatisaconstructor.mdwn b/hurd/ng/whatisaconstructor.mdwn index 3f05a37a..583babe9 100644 --- a/hurd/ng/whatisaconstructor.mdwn +++ b/hurd/ng/whatisaconstructor.mdwn @@ -3,4 +3,4 @@ TBD, see: * <http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00157.html> * <http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00056.html> --- [[Main/TomBachmann]] - 16 May 2006 +-- [[TomBachmann]] - 16 May 2006 diff --git a/hurd/ng/whatisaspacebank.mdwn b/hurd/ng/whatisaspacebank.mdwn index d7961210..607501db 100644 --- a/hurd/ng/whatisaspacebank.mdwn +++ b/hurd/ng/whatisaspacebank.mdwn @@ -1,3 +1,3 @@ TBD, see e.g. <http://eros-os.org/design-notes/SpaceBank.html> or <http://eros-os.org/papers/shap-thesis.ps> --- [[Main/TomBachmann]] - 31 Aug 2006 +-- [[TomBachmann]] - 31 Aug 2006 diff --git a/hurd/ng/whatsinagroup.mdwn b/hurd/ng/whatsinagroup.mdwn index 122f2012..219f4ed0 100644 --- a/hurd/ng/whatsinagroup.mdwn +++ b/hurd/ng/whatsinagroup.mdwn @@ -1,3 +1,3 @@ TBD, see <http://lists.gnu.org/archive/html/l4-hurd/2006-03/msg00001.html> --- [[Main/TomBachmann]] - 20 Jun 2006 +-- [[TomBachmann]] - 20 Jun 2006 |