Re: thread ids, task ids and subsystems

[Marcus Brinkmann]

On Thu, Apr 03, 2003 at 12:39:48PM +0200, Niels Möller wrote:
> I think I've grasped that. With "privileged operation", I didn't think
> primarily about privileges required by L4 directly, but operations
> that a random hurd process aren't allowed to do. The reason I think
> allocation of new subsystem numbers should be privileged, in this
> sense, is simply that it's such a scarce resource.

On 64 bit arches they are not scarce, but of course for the time being that
is correct.

> > 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.
> 
> Ok, this means that all tasks will have a PID. So a PID is mandatory,
> coordination with proc may or may not be.

For the Hurd, yes, this is what I propose.  You can also think about it in a
different way: The version id is just the task id, ie, what is the port name
of a task now.  However, as this id is globally unique, it can also be used
as the PID (in Mach, port names are task specific).
 
> > 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.
> 
> The point of proc is to implement unix process semantics, which is
> quite complex.

Not just.  There is a variety of interfaces in proc.  Some of them are those
that represent the "host", like hostname and uname.  One exotic interface is
also proc_dostop, which stops all threads in a task except the current one
(without race condition).  Clearly, that is something that belongs into a
task server logically.

> I think it would be nice if one could put some
> primitive hierarchy and accounting into a lighter server than proc.

Let us say that this belongs into its own interface, and I agree.  If there
should be two distinct server processes, or one process implementing two
interfaces, that is something I am contemplating.  The reason I am
considering to have both logical interfaces (task and proc interface) in one
server (although glibc and other programs could assume they are distinct),
is only performance.  I have experienced problems to be able to call ps in
the Hurd under heavy load, and I suspect that one reason was the polling of
the task list from Mach.

> Well, the task server needs to know about all tasks, and the proc
> server needs to know about all processes.  These are normally
> approximately the same, but when they differ (when a task haven't
> registered with proc), proc shouldn't need to know much about it. proc
> needs a way to kill it (and should probably do that automatically when
> its parent or its parent's parent, which *is* registered with proc,
> dies), but that about all.

But it means that proc needs to get a list of all tasks to be able to show
them in ps.

I think the relationship between task and proc is that proc is a superset of
task, in the sense that proc needs to know everything that task knows about
the processes, and some more.  In such a situation, I believe that it can be
a performance advantage if proc implements task itself.  Note that because
proc needs to be as privileged as task is, there is no disadvantage on the
security side either.

It doesn't mean that programs can assume that proc and task are the same
server, and it doesn't mean that you could not have it as two servers if you
want to, or reuse the task interface in some other system.

I don't want to jump to conclusions, but I want to keep it as an option. 
There is a unique relationship between task and proc, and I think that there
is some potential here for a real performance gain without compromising on
design.  Is there any situation you can think of where a single server for
the task and proc interface would harm you in your freedom to setup the
system?  Maybe, but I believe that any such feature (what could it be?
persistence? in-place updates?) is not something we will see happen in the
near future.

> What would the task server need to do?

Important question, but I am not going to tackle it right now. ;)
Certainly a lot of what you said, although for some features I am not sure
where exactly they belong.

>   * Get and set (some) resource limits, like cpu time and amount of
>     memory. Limits apply per accounting id. Things like the "number of
>     open files" are unknown to the task server. It's not clear to me
>     at all which server should enforce limits on the number of open
>     files. It doesn't fit well with the delegated filesystem of the
>     Hurd.

The number of open files is not a scarce resource at all in the Hurd.  The
underlying question is how to account for server side memory and processor
time (a filesystem server needs some memory and threads to process the user
requests).
 
Amount of memory is an issue for the virtual memory server.

Thanks,
Marcus

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