[Top][All Lists]

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

Re: thread ids, task ids and subsystems

From: Marcus Brinkmann
Subject: Re: thread ids, task ids and subsystems
Date: Thu, 3 Apr 2003 03:51:08 +0200
User-agent: Mutt/1.5.3i

On Wed, Apr 02, 2003 at 11:00:43PM +0200, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> > Hurd systems code the task id in the thread id.  So a Hurd server can tell
> > from which subsystem and task an RPC comes, and take appropriate security
> > measures.  The task ID will of course be the PID (and a more global PID can
> > be constructed from the subsystem id and the task id).
> Are you saying that PIDs will be allocated by the root server (or some
> other privileged) server, not by the proc server? (As it's not
> mandatory for tasks to register with any proc server, and definitely
> not with a privileged one).
> Must a subhurd have a different "subsystem id" than its parent? I hope
> not, since allocation of a new subsystem id sounds like a privileged
> operation, and creating a subhurd shouldn't require any special
> privileges.

You are mixing up a couple of concepts here which are not stricly related.
First, in L4, many operations that are not privileged in Mach are in fact
privileged.  This includes task (address space) and thread creation.  Only
the threads in the initial address space (let's call it root server) are
entitled to these operations, and there is no way in L4 to delegate the
privilege.  So you absolutely must delegate the operation (they operation
must be done by these threads on behalf of other threads).

This applies regardless of the policies in the operating system you want to
implement.  So, if you would want to write a mach server on top of L4, you
would just accept a thread creation request from any thread in the system,
and forward it to the root server.  If you want quota restriction, you need
to check this, and in general you need to define the policy yourself.

If you read my proposal for the root server, you will note that the concept
of subsystems was carefully designed to meet two goals:
1. Do not impose any policy on subsystems.
2. Allow subsystems to run independently from each other.

The way it works is that the root server just splits up the thread number
space in equal parts for the subsystems, and marks some of these threads as
"privileged" (ie, those threads requests are accepted and forwarded to the
kernel by the really privileged threads).  There will be one such delegator
thread per processor in the root server (so it doesn't impose a bottle neck).

However, the root server does not check anything else.  In fact, subsystems
are free to stomp on each other's threads (it would be easy to make
additional restrictions, but I think that's not necessary or useful without
a more detailed concept of subsystems - you could develop something like the
mainframe operating system of the S/390 if you want).

This answers your first question, PIDs (in Hurd subsystems) are set by
whatever calls on the root server to create or rename a thread.  The version
ID is not set or checked by the root server, nor does it care what it is
used for.

Now, what does in fact create PIDs?  It could be a dedicated task/thread
server, which would position itself between the root server and the Hurd
system as we know it today, and implement a part of the Mach interface (the
task/thread related interface of course).  That would blend in with the proc
server as an optional Hurd server as we know it today, and grant
unrestricted access to thread and task creation to every task/thread in the
same subsystem.  But I don't want to stop there, as I don't want to reinvent
Mach.  I think that we should take the opportunity and revise everything,
and add features like process accounting, quota, and process hierarchy. 
Well, if not add them, at least make it possible to add them without a major
redesign.  Also, some things in proc might become simpler if proc is the
only entity creating new tasks.

I have not made a thorough analysis of how I would like the proc/task/user
relationship in the L4 port of the Hurd, but that is something I have given
some thought, and it is not at all clear to me that the current
implementation in the Hurd based on Mach is the most desirable one.

Now, you throw subhurds into the discussion, which I tried to avoid.  Sure,
you could run several Hurd systems in parallel by using subsystems, but
subsystems are so independant that you can not, for example, get a list of
all tasks in another subsystem without some substantial cooperation between
them.  So, this is even more of a separation than we are used to.  (For
example, you could not use the controlling terminal in one Hurd as console
of the other Hurd).

So, you also want the option of booting a subhurd inside the subsystem you
are running in.  This is the only way to actually enforce the existance of
the subhurd as part of the (unprivileged) users environment - considering
quotas, process accounting etc.  Now, how to do that?  If you have the task
server separate from proc, you could just use the same task server in the
subsystem, and everything works as it does today.

But that is something you are really free to choose.  If you want to emulate
user-level subsystems, you write a proxy root server that bites off even
more bits from the thread id to add more subsystems (this would require some
cooperation from the other servers allocating threads).  Or you write a
proxy task server.  Or even a proxy proc server.  I can not say what makes
most sense without having an actual idea what servers there will be :)

Remember that we have to replace Mach almost entirely with new individual
servers.  In some aspects, it might be better to refactor the current
servers to reduce communication overhead (for example, proc currently polls
the task list, which is quite slow - if it were to allocate and destroy
tasks, it would always know which tasks exist and no polling would be
necessary - otoh, proc also does all the POSIX signal stuff, which you
probably want or want not to keep separate from task/thread management - I
am not sure that there is harm in having it in, though, as tasks still could
refuse to implement the signal interface or advertise a signal thread to

So, proc might become mandatory to use, but only a part of its interface. 
Or there might be two distinct servers, and some of procs interfaces move to
this otehr server.  Currently I am more in favor one server because
otherwise you have data redundancy (both the task server and proc would need
a list of all tasks).  This is only one aspect, others are touched above,
you get the idea.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

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