Re: kernel command line

[Marcus Brinkmann]

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