Ingo Molnar wrote: > * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > Dang. > > > > I guess we'll have to bite the bullet some day and actually create > > some explicit topological ordering of initcalls rather than depend on > > the initcall levels and link order. That is one particular complexity > > I've tried to avoid. But the subtlety of the current ordering is > > certainly not at all good either. > > 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? Why calculate this at boot time? Do you expect this to change between bootups? Eike
Attachment:
signature.asc
Description: This is a digitally signed message part.
