Le 19/02/2016 00:19, Rainer Weikusat a écrit :
> 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).
Yes, you are right, I've abusively shortened the chain.
> 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.
Dennys abandons the concept of runlevel for a more fine-grained
control.
Didier
::
Re: [DNG] Lead BusyBox developer on…
