Link order madness :-(
A message that is not in the archive (sent off-list or not yet received): [email protected]
Jean Tourrilhes <[email protected]> said:
[...]
Quoted 6 lines
The problem is *not* the networking initialisation (I wish
people were *reading* my e-mails). The basic networking is initialised early enough. The various networking stacks could be initialised earlier, but I don't depend on them. Note that there might be a reason to initialise networking after the file system, so to do that we might need to insert a level betweenfs_initcall()anddevice_initcall().
If you insert enough levels, you are in another form of madness.
There should be a way of saying "This must be initialized after this, and before that" (the "before that" might perhaps be taken care of by the "that" itself). Spiced with a few "barriers": "Networking inited", etc.
Quoted 1 line
From there the build system should figure it out by itself. tsort(1) on an
appropiate bunch of descriptive one-liners (extracted from the sources?) should give the right initialization order, or error out.
Yes, I know this has been proposed before and been thrown out (for no good reason, AFAICS)
Signature · 4 lines
Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Quoted 20 lines · Horst von Brand
Jean Tourrilhes <[email protected]> said:
[...]
Quoted 8 lines
The problem is *not* the networking initialisation (I wish
people were *reading* my e-mails). The basic networking is initialised early enough. The various networking stacks could be initialised earlier, but I don't depend on them. Note that there might be a reason to initialise networking after the file system, so to do that we might need to insert a level betweenfs_initcall()anddevice_initcall().If you insert enough levels, you are in another form of madness.
There should be a way of saying "This must be initialized after this, and before that" (the "before that" might perhaps be taken care of by the "that" itself). Spiced with a few "barriers": "Networking inited", etc.
Quoted 8 lines
Quoted 1 line
From there the build system should figure it out by itself. tsort(1) on an
appropiate bunch of descriptive one-liners (extracted from the sources?) should give the right initialization order, or error out.
Yes, I know this has been proposed before and been thrown out (for no good reason, AFAICS)
Throwing in my $.02. /etc/rc.d/* seems to have 100 levels (00 through 99) and it (so far) appears to be pretty sane, from my perspective. While 100 levels are perhaps too many, would it be more reasonable to have, say _early_initcall, _initcall, and _late_initcall for each of the categories (arch, fs, device, etc.)? This would allow more granularity within levels so things needn't ever be improperly promoted out of their rightly-named level. Prolly not, just thought I'd ask.
--Nathan
Hi,
Quoted 3 lines · Horst von Brand
There should be a way of saying "This must be initialized after this, and before that" (the "before that" might perhaps be taken care of by the "that" itself). Spiced with a few "barriers": "Networking inited", etc.
Suggestion #1: make up an inittask table (bad idea, huge table) that gets freed on end of init.
Suggestion #2: each big subsystem (net, scsi, pcmcia, etc.) gets a lock that is engaged when starting, and is checked by the subsystems. The subsystems' init won't take place unless the parent subsystem is up. At end of init, these locks get freed.
Suggestion #3 (possibly the worst ever): let the subsubsystems be init'ed by the subsystems, using #ifdef'd calls...
I must leave now, sorry.
Regards,
Thunder
Signature · 4 lines
ship is leaving right on time | Thunder from the hill at ngforever empty harbour, wave goodbye | evacuation of the isle | free inhabitant not directly caveman's paintings drowning | belonging anywhere