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.
> i think the topological ordering should not be just an extension of the

quoted text
> 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:
> so instead of the current hardcoded levels:

quoted text
>

>   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/