On Mon, May 14, 2001 at 02:59:43AM -0400, Roland McGrath wrote:
[msgport, boot command line etc]
What you write makes sense. I didn't notice msgport before. It looks like
it's a great tool.
> > BTW, what output can we expect from a pstree on the Hurd? Will the hierarchy
> > of a sub-Hurd shown in the parent system, or is this information lost?
>
> No, there is no hierarchy of tasks in Mach. The "parent" task on which the
> task_create call was made is only used as the initial VM address space to copy.
I have yesterday detected the tasks items about these issues:
* Mach needs a facility to find out what task is the parent of
a given task.
* A way to have the kernel send a message on some designated port
everytime a new task is started.
> Only proc keeps the notion of process hierarchy. So, if there are two
> Hurds then each one just sees all the other's tasks as "unregistered" tasks,
> i.e. they show up in ps but you can't really do anything but kill -9 them.
>
> I have previously considered adding a feature to Mach that would allow proc
> to keep track of hierarchies of unregistered processes. Then it could
> assign each unregistered process the owner, pgrp, etc. of its nearest
> registered ancestor process. This should make it possible for non-root
> users to run sub-hurds and debug or kill the sub-hurd tasks from the
> original hurd.
Right. There is certainly some Mach support necessary for this.
> Basically, there would be a send right associated with each task that you
> can only fetch or set via the host privileged port, and which is copied
> into new tasks by task_create. proc would then set this port on each
> registered task to something unique to that process that proc will
> recognize later. When proc comes across an unregistered task, it can
> extract this port value and know what registered task created the mystery
> task. Then it can assign parent PID and propagate the owner uid and so
> forth from the creator task. When unregistered tasks create more tasks
> before proc notices them, this might sometimes miss the intermediate
> hierarchy. But it will always attach unregistered tasks to either directly
> or indirectly to the closest ancestor that is a normal Hurd process, and so
> have a correct propagation of uids, if not an entirely accurate setting of
> ppids.
Yes, this would work out the way you described it. How about Mach keeping
track of the task hierarchy? I am not sure how exactly this would need to
be implemented. Mach could keep a pointer to the parent task in the task
structure. Someone having the host control port (?) could extract a send
right to this parent task port. Proc can match this (? does proc keep a
send right to every task? Have to check.).
However, I am not sure what happens if the parent task dies.
If proc keeps a send right, it will become a dead name. Then we just have
to make sure that we will return the same dead name on request.
I don't even know if tasks should be reparented, or if they become isolated.
> > Where do I have to look to find out how proc is informed about arbitrary mach
> > tasks that are not registered voluntarily?
>
> proc/mgt.c:add_tasks. When confronted with a task port not already in its
> hash table, it asks the kernel (host priv port) for all the tasks in the
> system and adds new tasks to its hash table. This is when the PIDs are
> assigned.
A new task notification as mentioned in the tasks list would make this
cleaner, right?
Thanks,
Marcus
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
