At Thu, 10 Mar 2005 00:04:39 +0000, Matthieu Lemerre <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
