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)
