[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Task server thread and task allocation/deallocation interfaces propo
From: |
Matthieu Lemerre |
Subject: |
Re: Task server thread and task allocation/deallocation interfaces proposal |
Date: |
Thu, 10 Mar 2005 03:21:40 +0000 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
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
- Task server thread and task allocation/deallocation interfaces proposal, Matthieu Lemerre, 2005/03/04
- Re: Task server thread and task allocation/deallocation interfaces proposal, Neal H. Walfield, 2005/03/04
- Re: Task server thread and task allocation/deallocation interfaces proposal, Matthieu Lemerre, 2005/03/05
- Re: Task server thread and task allocation/deallocation interfaces proposal, Marcus Brinkmann, 2005/03/05
- Re: Task server thread and task allocation/deallocation interfaces proposal, Matthieu Lemerre, 2005/03/07
- Re: Task server thread and task allocation/deallocation interfaces proposal, Matthieu Lemerre, 2005/03/09
- Re: Task server thread and task allocation/deallocation interfaces proposal, Marcus Brinkmann, 2005/03/09
- Re: Task server thread and task allocation/deallocation interfaces proposal, Matthieu Lemerre, 2005/03/09
- Re: Task server thread and task allocation/deallocation interfaces proposal, Marcus Brinkmann, 2005/03/09
- Re: Task server thread and task allocation/deallocation interfaces proposal,
Matthieu Lemerre <=
- Re: Task server thread and task allocation/deallocation interfaces proposal, Marcus Brinkmann, 2005/03/09