/hurd/init and /hurd/proc

[Justus Winter]

Hi,

I'd like to get some input. For context, please read Guillems message
http://lists.gnu.org/archive/html/bug-hurd/2006-02/msg00081.html and
Marcus critique
http://lists.gnu.org/archive/html/bug-hurd/2006-02/msg00082.html

Looking at his patch and having seen some mach message passing code in
the last few days, I'm confident that I could implement either
option. But first I'd like to suggest a third.

3) /hurd/init could be merged into the proc server.

/hurd/init does lot's of process related stuff, like starting
essential servers (like the proc server, and then *later* correcting
the proc servers state with respect to the essential servers started
by init using some specialized messages), keeping track of processes
that are essential and those worthy of being notified of a system
shutdown. Currently it also collects orphaned processes, though that
job is best left to sysvinit in the future.

This special interface they both use and the fact that init does lot's
of process related things might be an indication that the seperation
does more harm than good. It seems to make the code more complex, and
fixing the issue of killing essential processes will probably involve
adding more specialized messages that are only used by those two
processes. Is there a benefit of having them separated?

This would also have the nice side effect of freeing up pid 1 for
sysvinit.

About the pid 1 issue, I thought about patching the proc server to
reserve pid 1 for sysvinit and just make our init pid 4 or
something. Pino mentioned something about hardcoded assumptions of
which hurd server has which pid. Where would I find such assumptions
documented? Or could you provide anything from the top of your head?

But then again, this feels wrong and hacky. Since I learned about the
kill(0, x) issue and thought about what our init is currently doing, I
kind of lean towards merging proc and init and simplifying the code
and fixing both problems in the process.

Cheers,
Justus