Re: thread ids, task ids and subsystems

[Marcus Brinkmann]

On Mon, Apr 07, 2003 at 06:41:05PM +0200, Niels Möller wrote:
> Debugging is interesting, one would definitely want to be able to
> attach gdb to a task. I don't have much clue about what gdb needs in
> order to control a target, but it seems that there should be some
> interface for that that will belong to the task server.
> 
> The access rule should probably be that one is allowed to debug a task
> if and only if one is allowed to debug the process which the task
> belongs to. Which really is proc's decision, so I guess one needs some
> cooperation between proc and task (task shouldn't know about the
> ideosyncracies of unix process persona).
> 
> Hmm, perhaps the simplest way of sorting it out is to have a
> list_tasks call in task (I'm assuming anybody is allowed to list
> tasks), but make the calls to kill a task or create a "debug port" to
> it privileged in task, with corresponding calls in proc that do the
> access control thing and then passes messages on to the task server.

That is how it is done today.  In essence, tasks and threads are represented
by ports (kernel objects in Mach), which require the host control port
(privileged in the Hurd).  Proc supports two calls, proc2task and task2proc
that give you access to task port if you have the proc port and vice versa. 
I think you can only gain the proc port if you have access.  Getting a list
of all task ports from Mach is privileged, too.

This makes a lot of sense, and is possibly what is required here.  Although
I wonder if certain optimizations are possible.  One thing I think that
makes sense dropping is the idea of thread ports: Instead, a task port gives
you access to all threads in the task.  But I am not sure what thread ports
in Mach are useful for so I don't really know at this moment what limitation
would arise from that optimization.

creating the equivalent of task ports in the l4 task server sounds overkill
at first, but you really need it if you want to make it possible at all to
grant one process/task A access to a totally different process/task B, as is
possible in the Hurd (all accounting groups and other structures aside). 
So, although this definitely introduces quite hurdish concepts into the task
server, I don't really see a way out, unless you want to route *all* task
manipulating calls through proc itself (something you didn't want to :).

Also, the task server will be special in that it provides one thread for
each processor.  But you don't want as many ports representing the same
task (one port per processor).  So I think that there should be special
wrapper code that automatically calculates the "port number" (really: the
thread id of the receiver in the task server) by adding the processor number
(starting at 0) to the thread number in the thread id of the task "port"
(which is really just the base thread id in the task server together with
the number representing the task - favorably simply the pid).

OTOH, maybe we really want to add this base thread id +
(processor number << bits for version id) model to all Hurd servers, and
make it the norm rather than the exception.  We'll see I guess.

I have wrapped my mind an hour or so around solutions that try to avoid such
a sophisticated access control system in the task server itself, and just
exploit the accounting ID grouping and other things, except that they just
don't work and don't offer the criteria we need.



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/