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

[Matthieu Lemerre]

Marcus Brinkmann <address@hidden> writes:

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

I must confess that I don't know exactly how capability passing will
look like.

Moreover, I thought that there would be one PID for one task group (so
there would have been one PID for several 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.
>

OK.  In fact, I was trying to figure out how proc could have a control
over every task, but I completly forgot that there was already a ihash
in task server that did the task_id_t => task_t conversion. (Which is
needed anyway for task info capabilities).

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

OK.  Now I better understand that issue.

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

OK.

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

Well, thank you very much.  I now understand my mistakes (which means
that I learned quite much, don't we learn by doing mistakes? :))

Matthieu