Re: Hurd Projects

[Marcus Brinkmann]

On Sun, Dec 23, 2001 at 01:11:32AM +0100, Moritz Schulte wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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 brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de