Re: kernel command line

[Roland McGrath]

> The original Hurdish ancestor only has to remain alive for long enough
> for proc to establish its record and copy the owner ID.  If the kernel
> actively notifies proc as soon as the process is created with this
> information, we can be guaranteed it gets captured and recorded.

I have been assuming that in your proposal task_create completes without
waiting for this notification to be received and processed.  If the
notification is a message containing the task port of the creator task,
then this will arrive as MACH_PORT_DEAD if the creator task dies first, no?
So a task doing task_create,task_terminate(self) in quick succession could
create a child task that is cannot be properly recorded.  This is the sort
of violation I have been imagining.  I am not really comfortable with
relying solely on proc's high scheduling priority to guarantee this race
won't happen.

Anyway, it seems to me that spontaneous notifications from the kernel to
proc are just overkill as far as generating extra context switches and work
in proc shortly before proc will usually be woken up for the registration
of the process anyway.  

I feel much more comfortable with the inheritance-oriented approach to
tracking task creators.  As for process accounting, I would think that
having the creation_time records and a lazy recording in proc would be
sufficient.  The information accounting wants (command, arguments, etc) are
not really fetchable until after the process has been registered (or
perhaps not even until after the msgport is set).  If accounting should
record something about unregistered processes, I guess proc could look
periodically for them.  Unregistered processes that ran only a very short
time might not get accounted, but that is probably ok.

I am not really against a task creation notification thing, I am just
against relying on that for guaranteed task creator identification.  I'm
also dubious about the wisdom of spontaneous message traffic to proc as a
performance issue.