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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:16 EST