[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd Projects

From: Marcus Brinkmann
Subject: Re: Hurd Projects
Date: Sun, 23 Dec 2001 00:17:27 +0100
User-agent: Mutt/1.3.24i

On Sat, Dec 22, 2001 at 08:04:29AM -0700, mike burrell wrote:
> Marcus Brinkmann ( said:
> > On Fri, Dec 21, 2001 at 09:00:21AM -0700, mike burrell wrote:
> > > deniability".  unfortunately Hurd doesn't offer namespaces a la Plan9, as
> > > that would make things easier.
> > 
> > What is this namespace a la Plan9 feature?  Maybe we do have it in disguise
> > or can easily provide it.  Our name space is the filesystem, and it turned
> > out to be amazingly flexible so far.
> namespaces are basically filesystems (or pieces of filesystems) that exist
> on a per-process basis.  there's a paper on it (a little bit long) here:

Ok.  Well, if I understand it correctly, the main difference here is that
Plan 9 uses per-process filesystems by default (can it use a global filesystem?
I don't know), while the Hurd has a global filesystem that is used by all
processes by default.

However, chroot is your friend.  What defines the "filesystem" of a process
is really two things: the port to the root filesystem, and the port to the
current directory.  The port is stored by glibc, and inserted into the child
processes by the fork implementation.  chroot works by replacing the root
directory port by a port to the directory that you chroot in.

Note that by doing this, you loose the original root directory.  If you
don't hold other ports in the tasks that point back to the root directory,
your task is isolated filesystem wise, and lives in its own filesystem.

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.  The Hurd allows to override the fork implementation in
user space, as it exists in glibc.

So, writing a translator that provides a plan 9 per-process filesystem and
replacing fork to spawn such a filesystem and use it as the root port is one
big step towards emulating/implementing Plan 9 in the Hurd.  It would not be
very efficient, and maybe it can't give you the full Plan 9 for some reason
(I don't know Plan 9 after all), but it gives you per-process filesystems.

Maybe it makes sense to have one filesystem (translator) providing the
per-process filesystems for all processes.  Then you could make fork()
simpler by using /plan9-emu/$PID as the root directory port for a plan 9
process, or something like that.

So, we don't offer per-process filesystems by default, but it seems to be
definitely within reach on the Hurd, in user space, and without too much


`Rhubarb is no Egyptian god.' Debian
Marcus Brinkmann              GNU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]