On Tue, 30 Sep 2008, Ingo Molnar wrote:
quoted text
> 
> incidentally, i've been talking to Arjan about this recently in context 
> of the CONFIG_FASTBOOT feature. Because, as a side-effect, in the long 
> run, once the dependencies between initcalls fan out in a more natural 
> way, with explicit initcall ordering we'll also be able to boot a bit 
> faster and a bit more parallel.

Hell no.

We do not want any implicit parallelism in the initcalls. That way lies 
madness.

The probe functions that explicitly know that they are slow (like USB 
detection and/or other individual drivers that have timeouts) should put 
themselves in the background. We should _not_ use the dependency chain to 
do so automatically, because for most cases drivers are totally 
independent, but we still want a _reliable_  and _repeatable_ ordering.

Which means that I will not accept stuff that makes for a parallel bootup 
as a general initcall notion. I want things like network devices to show 
up in the same order for the same kernel, thank you very much - even if 
there is absolutely _zero_ ordering constraints between two independent 
network drivers.

Anything else will inevitably cause just totally random and undebuggable 
problems.

quoted text
> i think the topological ordering should not be just an extension of the 
> current hardcoded initcall levels, but it should be symbol space based: 
> i.e. an initcall should depend not on some kind of artificial enum, but 
> it should depend on _another initcall_. (a list of initcalls more 
> generally)

Yes, it should be explicit.

However, I don't agree with the notion of having initcalls point to other 
initcalls. One big _idea_ of initcalls is that you can put them anywhere 
in the source code, and that CONFIG_XYZ variables will automatically run 
them or not depending on whether the code was compiled in. Having 
something like:

quoted text
> so instead of the current hardcoded levels:
> 
>   core_initcall(sysctl_init);
> 
> we could have natural constructs like:
> 
>   initcall_depends_on(sysctl_init, securityfs_init);
>   initcall_depends_on(sock_init, sysctl_init)

would be a TOTAL DISASTER, because if you do that, then you are 
essentially back to the insane situation where people need to know what 
other parts are enabled.

So no. No "one call depends on another" crap.

But I think we could add a separate notion of a dependancy point, and have 
a setup where we describe "initcall X needs to happen before point A" and 
"initcall Z needs to happen after point A".

And then we can create a separate set of these dependency points, so that 
X and Y don't have to know about each other, they just have to have some 
knowledge about some common synchronization point - one that exists 
regardless of whether X or Y are even compiled in!

			Linus
--
unsubscribe notice
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/