Didier Kryn <k...@in2p3.fr> writes: > Le 19/02/2016 00:19, Rainer Weikusat a écrit : >> 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). > > 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". _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng