refactoring rc.sysinit

[Josh Aas]

Hello,

The following is a proposal for modularizing Red Hat's 
/etc/rc.d/rc.sysinit script. This proposal solves the problem of having 
to patch rc.sysinit and respin the RPM when modifying the rc.sysinit 
process (instead, simply add a script to a directory).

It would be nice if rc.sysinit was broken into chunks and organized in 
separate files, similar to what was done with init.d. The following 
scheme should mesh fairly well with the way /etc/rc.d is already set up 
on Red Hat systems, and it also closely (but not exactly) follows 
conventions used in Debian and Gentoo systems, as well as others (e.g. 
symlinks in an rcS.d directory to init.d/* scripts).

- Each chunk of rc.sysinit would be a file in a directory 
"/etc/rc.d/init.d", prefixed by "boot.". So, the "example" section of 
rc.sysinit would be "/etc/rc.d/init.d/boot.example"
- a new directory, "/etc/rc.d/rcS.d", would contain symlinks to scripts 
in "/etc/rc.d/init.d". These symlinks would start with "S" and then a 
two digit number, then the script name, with the numbers ascending in 
the order that the scripts should be run. This is similar to what is 
done with rcX.d scripts, where "X" is any runlevel.
- The rc.sysinit script itself would remain, and it would be the script 
that calls scripts in rc.sysinit.d in the appropriate order. This means 
that nothing else in the boot setup would need to change since running 
rc.sysinit until completion would still be all that needs to be done. 
That mechanism is already in place, obviously.

Given way rc.sysinit is written now, a shift to this scheme is not 
exactly straightforward. I tried to write a patch for this during a 
limited period of time I had, but I wasn't able to finish as things got 
a little more complicated than I expected and having help from the 
beginning would be best. Perhaps there are better schemes? Also, having 
help from people who know more about the order of operations in 
rc.sysinit would be great.

Comments would be appreciated. I would be interested in such a scheme 
for the reason at the top of this email, but there are probably more 
benefits (why did Debian, Gentoo, etc. do it? Ease of maintenance?).

-- 
Josh Aas
Linux System Software
Silicon Graphics, Inc. (SGI)