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. However, I don't think we need to burden the Hurd's glibc by it. If all you want is an extra private name space in a process, you can just get it. I think libfshelp has support functions for that. You just start a translator yourself, without attaching it to the filesystem (note that translators can be attached and detached). (A translator is attaching itself by sending an RPC to the bootstrap port. If you start the translator, you provide the bootstrap port and thus get the RPC that requests attaching it to the filesystem, and you can act on this message as you want). Note that this does not give you the same as what I described to emulate Plan 9. All normal file lookups like "/dev/cons" will refer to the global filesystem, and you have to use file_name_lookup_under to get your private filesystem, so this is exactly what you described. Well, what you might want to consider is what happens at fork and exec. If you want the child to inherit the private filesystem port, that already happens in the current fork implementation. If you want it to survive an exec, you indeed need to add support for it into glibc. But why you'd want to inherit a private filesystem is a bit beyond me :) Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd