Jean Tourrilhes <[email protected]> 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)
--
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
Horst von Brand wrote:
>Jean Tourrilhes <[email protected]> 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
Hi,
On Mon, 3 Jun 2002, Horst von Brand wrote:
> 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
--
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