* Grant Grundler <grundler@xxxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 30, 2008 at 12:51:07PM -0700, Linus Torvalds wrote:
> ....
> > 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!
>
> We already do this today. :)
> Definitions are in include/linux/init.h.
> Point A would be "early" ("run before initialing SMP")
> The rest could use better definitions and AFAICT aren't that much better
> than being named "Point B".
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
--
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
