Boot Dependancies - a weird wacky wonderful new idea
Hello, I have an idea (ok, maybe not an original idea, but bear with me :)
It involves the sysvinit (/etc/init.d/rcS and a lotta other stuff) and
dpkg packages. (update-rc.d)
Parallelized booting. What this means is we run multiple bootup scripts
simultaneously. It's a *lot* faster on mid-to-higher-end machines, even
with just one CPU - it'd be wickedly fast with SMP.
"Hey wait a second that won't work!!! What if the netstd_nfs script runs
before the netbase script is done processing?"
Well, you're right, but I have another (slightly more original) idea that
will make it work. Boot-time dependancies.
* Instead of relying on those icky priority numbers we just had a flame
war or two about, the packages tell us how they *really* feel and state
precisely in a file (I'm thinking /etc/init.d/deps/[KS]packagename) what
needs to be successfully running (or not running) before or after they
can start. Do we need to make this information separate for each runlevel?
(i.e. make it /etc/rc?.d/deps/[KS]packagename instead?)
* /etc/init.d/rc is modified to call a program that determines the order
the scripts should be run in, on the fly. I figure this won't be much
of a speed hit. Slrn can thread thousands of messages per second across
a localhost news connection on my machine, sorting 30 scripts shouldn't
take long either. Actually, we don't even need to thread, we can probably
get away with just checking on script exit (any script exit) whether
there's something else available to run or not - if there's nothing else
available but there's still stuff that wants to be run, we can just run
it anyway.
* Because a fatal error on bootup is simply not an acceptable option,
dependancies are considered 'soft' - if a dependancy can not be met
for whatever reason, it is simply ignored. (This is what our existing
setup with priority numbers does anyway.) We'd want to keep a debugging
flag in the works to reveal such a situation though.
* update-rc.d is modified to ignore priority numbers and keep things in
the new format. (hmmm, perhaps we can be trickier than this.)
Problems looming:
* Installing new packages using the new dependancy format on older machines
without thread-scripts needs to be handled - perhaps we can keep the NN
switch to update-rc.d calls in new packages (at least for a while)
* Going back and forth from the old setup to the new one won't be a walk in
the park. I'd need to make a conversion utility.
* My coding skills ;)
I still have yet to create proof-of-concept code for this but the general
idea has created such a buzz in #debian that we might just see something :)
As for the file formats of /etc/init.d/deps/[KS]packagename, I was
thinking something along the lines of:
After: <packagename> <anotherpackagename> <etc>
Before: <morestuff> <goeshere>
I feel this information absolutely positively must be admin-editable, which
dictates some type of text file format.
Perhaps we could give it the idea of psuedo-packagenames such as 'everything'
so we can have 'After: everything' for Srmnologin and Sxdm.
i.e. /etc/init.d/deps/Sbind would have:
-CUT-
After: sysklogd kerneld netstd_init
-CUT-
If we are ever going to do this it would require at least the agreement of
Miquel van Smoorenburg, Klee Dienes, and Ian Jackson (current sysvinit and
dpkg maintainers) and a good concensus among the Debian developers,
preceeded by a LOT of discussion, so I figured I'd throw it out onto
debian-devel and await the replies: "so... what *is* that you're smoking?" :)
Please let me know what you think of this.
--
Robert Woodcock - rcw@oz.net
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: