Edward Bartolo <edb...@gmail.com> writes:
> System initialisation is NO religiously enshrined mystery that is
> highly claimed to be beyond human comprehension.
Was this supposed to have any relation to the text I wrote? If so, I'm
oblivious to it. As I tried to describe below, system initialization is
really not complicated per se. systemd is complicated because everything
done by these people ends up being a complicated solution to a simple
problem, I suggest pondering the deep wisdom in Hoare's
There are two ways to construct a software design. One is to
make it so simple that it has obviously no bugs and the other to
make it so complicated that it has no obvious bugs.
here.
> I can understand the position help by anyone that an init is so
> central to an OS that it must be coded scrupulously. And, given time,
> I think, I will eventually come back with something that can be said
> to be a functional and stable init.
Just like string libraries, init replacements are classic
rites-de-passage programming: Sooner or later, everybody ends up doing
one. I surely did. I wouldn't do this again, however, as the practical
value didn't justify the effort: I'm maintaining a sysvinit-fork because
that's good enough to build on and simple enough to adapt it to my needs
without undue effort.
> My current task if of trapping system wide events like requests for
> shutdown and reboot. My init will be used to call various scripts or
> executables depending on the type of event.
These aren't really "system-wide events", except as seen at a very abstract
level. There's a shutdown command which is part of the sysvinit package
whose purpose is to send a command to init to tell it to go to a certain
runlevel, runlevel 6 meaning reboot and runlevel 0 system halt. This is
passed to the configured runlevel change command (usually
/etc/init.d/rc) which executes the kill scripts in the corresponding
runlevel directory (/etc/rc0.d or /etc/rc6.d). The final script in
either directory start another command (halt or reboot) which
ultimatively triggers a reboot system call (=> reboot(2)) causing the
kernel to initiate a system reboot or poweroff.
>
> Edward
>
> On 18/06/2016, Rainer Weikusat <rweiku...@talktalk.net> wrote:
>> Lars Noodén <lars.noo...@gmail.com> writes:
>>> On 06/17/2016 09:36 PM, KatolaZ wrote:
>>> [snip]
>>>> Unfortunately, system initialisation is really a bit more complicated
>>>> than that, whether you like it or not.
>>> [snip]
>>>
>>> Is there a concise summary somewhere of what system initialization
>>> entails? Or is it dependent on accumulated experience and not codified?
>>
>> This depends heavily on what the system is supposed to do. Eg, something
>> fairly specialized running a single application could just run the
>> application as sole process instead of init. For something more general,
>> there'll be a static initialization step which will usually include
>> creating an initial filesystem namespace by mounting some set of
>> filesystems (some virtual, eg, proc and sys, others residing on real
>> devices) and my also include configuring some set of network
>> interfaces. Afterwards, a set of programs performing various functions
>> is started, eg, web server, name server, ssh server or so-called gettys
>> enabling interactive logins without going over a network.
>> _______________________________________________
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
