Marcus Brinkmann wrote: > On Sun, Dec 23, 2001 at 01:11:32AM +0100, Moritz Schulte wrote: >>Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>>[per-process namespaces] >>>So, you could emulate Plan 9 on the Hurd by replacing the fork >>>implementation with something that creates a new plan 9 like >>>per-process filesystem and uses that root directory port as the root >>>directory port of the child process. >>But simply replacing the root port of the child wouldn't be nice, >>because usually programs want to access the root file system (for >>data, whatever) to function properly. > This can be done by the special per-process filesystem, too. Note that this is a > full-blown translator, which can provide whatever abstractions it wants. It > can also give access to the "underlying" global filesystem through /global/, > or by some other means. It all depends on how it works in Plan 9, of > course. If in Plan 9 there is a global filesystem, and how it is accessed. > If it is accessed by a directory in the per-process fs, then another port is > not needed. If it is accessed by special library calls, and you are not allowed > to mirror it into the per-process fs (in some subdir), then you need to put > the support for it in the special version of the glibc library (which also > has the other fork etc). This is what you described. I would like another approach: `myfs' translator on '/my' node. Then (please don't change your face ;) `/my/documents' will be user-specific or process-specific directory depending on who asks. This translator can become quite complex considering, for example, it can be `shadowfs' on per-process, per-process-group, per-session, per-user and per-user-group virtual filesystems with all needed object interfaces to control it :) Just an idea. Regards -- Ognyan Kulev <[EMAIL PROTECTED]>, "\"Programmer\"" _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
