refactoring rc.sysinit

[Tyler Larson]

Bill Nottingham wrote:
> Nils Philippsen (nphilipp at redhat.com) said: 
> 
>>In the past, I found myself in some situations where I would have loved
>>to do things before or after a certain stage in rc.sysinit. How things
>>were, I had to change the file itself which either made me retrofit
>>these changes to a new rc.sysinit or lead to surprises when updating
>>initscripts.
> 
> 
> Got example usage cases? I'm just skeptical of making things more
> complicated and slower if the only usage cases are theoretical.
> 
> Bill
> 

I know it would have come in handy when I was modifying an old FC box to run 
off a read-only drive (long before the Stateless Linux project). I had to 
change the way it mounted /, create and initialize some ram disk, and some 
other little goodies that, for one reason or another, couldn't be put off till 
later. rc.sysinit makes a number of assumptions about the way you want your 
system to boot which are true almost all the time. Every now and then, though, 
you have to configure a box to do something weird.

On the one hand, on the occasions when you *do* have to modify the sysinit 
procedure, it would be much cleaner and easier if rc.sysinit took a more 
modular approach. On the other hand, those situations are so rare it's easy to 
not think about them.

There is also something to be said about the fact that modular code tends to 
be cleaner code. rc.sysinit feels a bit like a run-on sentence. It would be 
easier to understand and modify if it were broken up a bit. Not sure if it's 
worth a design change to fix that, though.