* Linus Torvalds  wrote:
> Dang.

quoted text
>

> 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?
	Ingo

--

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/