l4-hurd
[Top][All Lists]
Advanced

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

Re: Process hierarchies


From: Marcus Brinkmann
Subject: Re: Process hierarchies
Date: Tue, 11 Oct 2005 22:23:40 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 11 Oct 2005 15:51:51 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> The new child receives its initial capabilities from two sources: the
> parent and the constructor (I still need to explain the constructor).
> Either set, of course, can be ignored. It is very common for the
> capabilities supplied by the constructor to include verification
> capabilities (e.g. the ability to verify that a space bank capability
> names an official space bank).

I want to tie this in closely with the Hurd.  When I first heard of
constructors in EROS, I had difficulties to understand what they are
and how they work.  Your description makes it very clear, but for Hurd
people it becomes even clearer when you point out that we do have
something analogous to constructors in the Hurd.  Or rather, as you
pointed out in a different mail, we implement a special case.

In the Hurd, processes are usually _not_ created by the parent.
Instead, they are created by the filesystem that contains the
filesystem image.  The parent makes an RPC to the filesystem, which in
turn makes an RPC to the exec server (the exec server is gratuitous,
there is no strict need for it in the design).

Normally, the filesystem will just forward the initial capabilities
provided by the parent.  But for suid applications, the filesystem
will replace some of these initial capabilities with trusted variants.
This includes the root filesystem, authentication handle, process
server.  Actually, I am lieing.  Some of the work is done by the
filesystem, and some of the work is done by the exec server.  But the
net effect is the same, and if one would remove the exec server from
the design, the work it does would be done by the filesystem.

So, very losely, in the Hurd, the filesystem acts in the role of an
EROS constructor.  Clearly, the EROS solution is more generic, and
abstracted.  In the Hurd, this is just handled as a special case in
the filesystem for the suid case.

The analogy is even more complete.  Mach does not have a parent-child
relationship between processes.  In the Hurd, the parent-child
relationship is recorded in the proc server, but this is entirely
optional.  I would have to check when and from where this relationship
is recorded.

There is no analogy to spacebanks in the Hurd, as Mach does not
provide any way to control memory usage (Yeah!).  Similar for
scheduling.

I think this analogy can help people familiar with the Hurd to
understand what constructors are about, and start to explore further
applications of the concept that is realized much more generally in
EROS than in the Hurd.

Thanks,
Marcus





reply via email to

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