Didier Kryn <k...@in2p3.fr> writes: [...]
>> That's a theoretical argument I agree with: I think the server/ service >> management code shouldn't be part of init especially since it's >> virtually unused but that's really a tiny addition to the process >> starting code which more-or-less has to exist, anyway. > > Actually pid1 only needs to start one process, the real init, and > wait the zombies. The real init then takes care of mounts and starts > the services or starts a supervisor to do it. This would seriously > shrink pid1. init doesn't mount anything, anyway. On 'sysinit', it runs /etc/init.d/rcS which - in turn - executes the scripts in/ linked into /etc/rcS.d in the order of their names (the sysinit command can be changed via /etc/inittab). It also usually doesn't start anything except gettys despite it could manage abitrary processes. The reason for it starting gettys is mainly that it contains the console-handling code which could be moved out of it. In case a runlevel change request is received, it executes /etc/init.d/rc with the new run-level as argument (also configurable, implements 'the runlevel stuff'). Lastly, it handles a few special-case control requests, UPS notifications and C-A-D, also by executing a command which can be configured via inittab. The problem with the special-case control requests is that the kernel sends these and init is the only process the kernel knows about. Since it's also the only process guaranteed to be available (and with a fixed pid), it's also a sensible choice for other, system-wide 'control requests', ie, runlevel changes, halt and reboot. Anything else could be moved into independent processes. OTOH, getting this to work requires a sizable amount of effort and this means only people working for 'OS distribution companies' who basically put their developers on "eternal gardening leave" unless there's an urgent support request they need to deal with and very dedicated hobbyists will ever accomplish something in this respect --- and both tend to favour complicated, flashy stuff instead of evolving the existing system to a point were most of the warts have been healed. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng