Didier Kryn <kryn@???> writes:
> 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.

Not really. Following the standard rules of this strange 'discussion',
you changed the topic away from what I was writing about (and what the
original text happened to be about) to something entirely different
which has a lose, conventional technical relation to the original topic
(sysvinit program) while keeping the same name.

[...]

>> 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.

The abstract definition of 'runlevel' is (as far as I'm aware of it):
"Set of processes supposed to be running". Considering this, one can
safely conclude that whatever 'Dennys' did, he certainly didn't to
that. A somewhat educated guess could be "he implemented something even
more uselessly specialized than the already overcomplicated convention
of having 4 distinct 'sets of processes which are supposed to be
running' during normal system operation plus maintenance, shutdown and
reboot modes".