Nils Philippsen (nphilipp@xxxxxxxxxx) 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.
