Re: thread ids, task ids and subsystems

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

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

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.

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

That's nice and clear. My questions are more about how this will be
used by the hurd servers.

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

> 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. I think it would be nice if one could put some
primitive hierarchy and accounting into a lighter server than proc.

I think we've discussed this to some length before, something like
associating an "accounting id/owner/responsible process" with each
tasks, which by default is inherited when new tasks are created, and
which can't be changed except by cooperation with proc, and
accumulating resource for tasks with the same accounting id. For
concreteness, I'm drafting an interface for that at the end of this
message.

For tasks that haven't registered with proc, you don't have a full
parent-child hierarchy, you only have anough information to associate
an "owner" to each task. I think that's all you need.

> and it is not at all clear to me that the current implementation in
> the Hurd based on Mach is the most desirable one.

There's a line between "system servers that a user can replace at
will", which is the Hurd proper, and "system software which an
ordinary user can't mess with". On Mach, that line was approximately
the line between the Mach kernel and userlevel. On L4, the "non-Hurd"
part has to include both L4 and system servers like the root server,
memory server, some or all device drivers, perhaps task server, ...

I think it's excellent to design the non-Hurd parts so that they could
be used for very different operating systems as well, that should
ensure that they will work also for Hurd users that want to do weird
things.

> Now, you throw subhurds into the discussion, which I tried to avoid.  Sure,
> you could run several Hurd systems in parallel by using subsystems,

You mentioned subhurds as one application of subsystems... 

> So, you also want the option of booting a subhurd inside the subsystem you
> are running in.

Right, that's the most interesting case, at least to me.

I think one would want to associate all the tasks in the subhurd with
a single process/task in the parent, perhaps the boot process. One way
to do that may be to use a proxy task server.

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

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.

What would the task server need to do? To each task, it would
associate a task id (stored in the version field of each thread, as
you suggest), and an "accounting id". Operations should include:

  * Create task (allocates a new task id. Inherits the accounting id
    of the caller). Perhaps it should also create the first thread?

  * Kill task. Privileged call. Allowed by proc, and perhaps by
    threads in the task itself, or perhaps with other tasks with the
    same accounting id.

  * Kill tasks. Privileged call. Allowed only by proc. Kills all tasks
    with the given acounting id.

  * Notify. Requests notifications on task creation and death, for all
    tasks, a particular task, or a particular accounting id. Probably
    not privileged?

  * Create thread, et al. Some variants for creating and individual
    threads, and requesting notifications. (The root server will allow
    the (privileged) task server to create tasks, but not random
    tasks, right?)

  * Change accounting id. Privileged call, only allowed by proc.
    When a task registers with proc, the accounting id is changed to
    the process PID (as chosen by proc).

    (This call can be made unprivileged, if task keeps the owner of
    each accounting id, i.e. a task can have <proc, 17> if it has PID
    17 and at the same time <100, 47> if task number 100 have assigned
    it an accounting id 47. This makes task more complex, but it seems
    to be a clean way to have for example a task in a subhurd be
    accounted both by the subhurd's own proc, and by the parent's proc
    server. On the other hand, the task do not need to know any id of
    the proc server apriori).

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

  * Get resource usage, for an individual task, or all tasks with a
    given accounting id.

  * List tasks, all tasks or all tasks with a given accounting id.

Does that make sense?

/Niels