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
