:: Re: [DNG] Lead BusyBox developer on…
Forside
Slet denne besked
Besvar denne besked
Skribent: Rainer Weikusat
Dato:  
Til: dng
Emne: Re: [DNG] Lead BusyBox developer on sysvinit
Didier Kryn <kryn@???> 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.