To: Linus Torvalds <torvalds@...>, Arjan van de Ven <arjan@...>
Cc: Rene Herman <rene.herman@...>, Bjorn Helgaas <bjorn.helgaas@...>, Jesse Barnes <jbarnes@...>, Len Brown <lenb@...>, Frans Pop <elendil@...>, Rafael J. Wysocki <rjw@...>, Linux Kernel Mailing List <linux-kernel@...>, <linux-pci@...>, <linux-acpi@...>, Adam Belay <abelay@...>, Avuton Olrich <avuton@...>, Karl Bellve <karl.bellve@...>, Willem Riede <wriede@...>, Matthew Hall <mhall@...>, Sam Ravnborg <sam@...>
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.
[ but performance is far less important than robustness, so this idea
was on the backburner. ]
and i think on the conceptual level initcall levels and implicit
ordering are bad in the same way SPL and IPL based locking is worse than
real, explicit spinlocks.
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)
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)
where we create explicit dependencies between actual initcalls just by
listing their dependencies. In many cases we could express dependencies
in a natural way:
initcall_depends_on(some_subsys_init, kmem_cache_init);
initcall_depends_on(some_subsys_init, sched_init);
which would express the fact that some_subsys_init() must execute after
kmem_cache_init() and after sched_init().
Each initcall is associated with an 'initcall descriptor', which shows
which other initcalls this initcall depend on, and whether the initcall
has been executed already.
during bootup the initcall engine would parse the graph and would
execute all the 'leaf' initcalls, and would complete the graph
gradually.
( More details: we'd have a number of compatibility and convenience
symbols as well - well-known initialization stages for various
customary phases of bootup.
And at link time we could detect circular dependencies. )
So ... this scheme looks elegant to me, but maybe it is overdesigned?
Ingo
--
