Re: Hurd Projects

[Ognyan Kulev]

Marcus Brinkmann wrote:

> 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.

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 <ogi@fmi.uni-sofia.bg>, "\"Programmer\""