Avery Pennarun writes: > What's wrong with priority levels? Programs start up in alphabetical order. > I wish they would die in reverse-alphabetical order (then we could have > S99xdm and K99kdm, which would make the file-rc package look nicer) but > priority levels do exactly what you want -- they express boot-time > dependencies.
No. I'd say priorities are a higher-level abstraction than real deps. You loose a lot of information when translating real deps into priorities, which can make it difficult in case of deps changes: one dep disapearing may well stay unnoticed, and thus not paralelized; one appearing may eventually cause trouble... > We can achieve a huge degree of parallelism simply by running all boot > scripts of each priority level in parallel. That is, run all scripts at > level 01 (and wait to finish), then run all scripts at level 02, and so on. > To see why this should be "parallel enough," look at the large number of > scripts running at the default level 20. ...which would mean that level 20 is nearly all that can be parallelized ? The only other duplicate priorities on my system are 2 S10 and 2 S50... I guess there may be some unnecessary distinct levels down there. > The hardest thing would be keeping the log messages from getting tangled up. > That shouldn't really be too hard for a C/C++ program to do. I've done > something almost appropriate in my wvdial package (see class WvLog and > WvLogRcv). Miquel told me some time ago of a boot-logging daemon he plans, that would save these boot messages. Maybe we should just modify boot sctipts to redirect their outputs individually through a bootlog facility, not unlike syslog ? That would just have to be done in "rc" itself ! Philip Hands writes: > This sounds like a job for make (which can run things in parallel) /bin/make ? That would just be the 3rd largest binary there, after bash and tar :( > [1] like make /etc/init.d/deps/[KS]packagename be makefile fragments that > get included into the master makefile. sure "include /etc/init.d/deps/*" is an easy thing. > You can use make's load/job limiting options to tune the best number of > things > to run at once. Yes. Maybe we can just add a series of #ifdef in make sources to make a /bin/boot-make that would have small footprint both in RAM and in / ? But maybe it's not worth the time to do it ? -- Yann Dirson <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]