On Tue, 30 Sep 2008, Ingo Molnar wrote: > > 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 > 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: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
