Cc: Linus Torvalds <torvalds@...>, Arjan van de Ven <arjan@...>, 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@...>
* Grant Grundler <grundler@parisc-linux.org> wrote:
the structural problem with the current level-based initcall design is
that the current dependencies are implicit (not spelled out clearly
anywhere in the source code), and bugs in them are often fixed by
experimenting around (seeing whether it breaks), not by design.
Changing it is a ton of work, and the risks of touching that code might
eclipse any (often marginal) advantages a new scheme has. Today boot
code runs only once and it is one of the most under-tested pieces of
kernel code. Boot code's quality and robustness is at least 1 order of
magnitude worse than regular kernel code.
But to play the devil's advocate: users have so many problems with weird
races in boot code today _already_, wouldnt it be better to expose boot
code to more variations, to put it under environmental pressure that
ultimately improves its quality?
Init code is often reused during suspend/resume, so by introducing more
flexibility into initcalls maybe we create enough pressure to fix them
when it's far easier to fix them. (after bootup - fixing after-resume
bugs is much harder because often the console is turned off and no
significant BIOS code ran.)
Today moving an initcall to another level has unknown effects and
nothing warns about broken dependencies but a bootup crash (often only
triggering under a specific .config), or a non-working device or some
other regression.
That is rather fragile and i doubt anyone can argue the opposite.
The question of whether explicit dependencies are better is another
question and up to debate:
in the long run it is _IMHO_ more robust to express explicit
dependencies close to the init functions, in the source code:
initcall_depends_on(this_driver, memory_init);
initcall_depends_on(this_driver, io_resources_init);
than to rely on the implicit (and undocumented and often forgotten)
dependencies we have currently.
For example ordering an initcall to after PNP init would be trivial,
we'd add this to the init dependency list:
initcall_depends_on(this_driver, pnp_init);
With the current scheme we have to find some other integer 'level' and
hope that moving this initcall to that new level does not break other,
implicit dependencies.
And note that once we start doing explicit dependencies, we could
automate much of it: if a piece of .o uses a set of symbols that makes
it rather clear which subsystems it has to rely on. Say it uses
kmalloc() then it should depend on memory_init() done.
Ingo
--
