Re: Task server thread and task allocation/deallocation interfaces proposal

[Marcus Brinkmann]

At Thu, 10 Mar 2005 00:04:39 +0000,
Matthieu Lemerre <address@hidden> wrote:
> I've been thinking a bit more on this, and I can write more clearly
> the two proposals of interfaces:

Consider the third one, too: Using no group IDs, but just task groups
(ie linked lists), no trees.  That seems to be the simplest one to me.

I found your description of what a process registration is to be vague
and errorneous, but let's not hold ourself up with that, it's
something we have to look at in detail later.  (IE, for example, PIDs
are always assigned, even to unregistered tasks).

> This ensure that for every task in a task tree, PROC has a control
> capability on its root, and so can destroy it.

Proc _always_ will have any arbitrary task capability, just by asking
for it.

You have done a good amount of convincing why explicit group IDs may
not be necessary.  But I don't see any convincing (or actually, _any_)
arguments for full tree support.  And, we really need to be able to
_see_ group relationships in ps output, something that you haven't yet
addressed (but it's possible of course - proc can even create the IDs
itself "on the fly", as long as it knows which tasks are lumped together).

> In fact, I was writing a pseudo task-user interface.  Last time I
> didn't wrote the l4_thread_id_t argument, and Neal pointed that out,
> so... :)

Well, it depends at which level you write the interface.  The task
server thread ID is implicitly contained in the task_t, at least from
the client's highest-level perspective.  In the user code, you will
always use the capability as the first argument, not the server thread
ID.  However, the capabaility is then not directly a capability
handle, but a pointer to a client-side struct that contains all
relevant information for capabilities (like reference counter etc).

> So, it is actually more a security issue to accept a task than to
> donate one, right?

I wouldn't say it that way.  If you _accept_ a task, you know about it
and can deal with it.

Thanks,
Marcus