Re: Link order madness :-(

[Nathan <wfilardo@fuse.net>]

Horst von Brand wrote:

>Jean Tourrilhes <jt@bougret.hpl.hp.com> said:
>
>[...]
>
>  
>
>>	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 between fs_initcall() and device_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.
>>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