Re: kernel command line

[Roland McGrath]

>  * Mach needs a facility to find out what task is the parent of
>   a given task.

I'm not sure if there was a particular motivation for this other than the
kind of thing in proc that I suggested.  I'm not sure there is a reason to
do the kernel interface I suggested (propagating a value that proc can set)
instead of simply adding a host-priv RPC to get the creator task.  If that
identifies the creator task by its task port, then that might be a dead
name and then all information is lost (you can hold distinct dead-name
rights and compare them uniquely against other dead names or rights, but
transferring them in a message always gives you MACH_PORT_DEAD).  

>  * A way to have the kernel send a message on some designated port
>   everytime a new task is started.

I think the need here was something that could be used to trigger process
accounting (acct).  

> 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.

We seem to be thinking the same things.  This is indeed the problem with
the straightforward feature using the task ports.  As I understand it, you
cannot transfer a dead name--it is not a port any longer.  A dead name is
just a placeholder in the task's port name space preventing that name from
being reused for a different port right until the user refs are all gone.

> A new task notification as mentioned in the tasks list would make this
> cleaner, right?

Well, there isn't really anything wrong with the current approach.  There
is a certain appeal in not having proc wake up and do things every time
task_create is called, especially when you think about having multiple
hurds.  Currently, it is lazy in the sense that it doesn't record anything
about a task until the first time it has to consider that task in order to
accomplish some particular thing.