Marcus Brinkmann <[EMAIL PROTECTED]> writes: > 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).
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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
