On Wed, Oct 01, 2008 at 10:26:03AM +0200, Ingo Molnar wrote:
...
> > 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.
Ingo,
I totally agree with you and liked yours/Arjan's suggestion to make
the dependency explicit. Since linus pointed out explicit dependencies
would be a disaster to maintain, I don't know where to go next. I agree
with him issues will come up. But frobbing the current scheme by increasing
the number of "init points" from 8 to 50 (or more likely a 100 or 200)
feels like it's not making the dependencies explicit either.
We currently make the subsystem/driver dependencies explicit in the
Kconfig files. We hide the lack of a subsystem with null macros
(e.g. "#define foo() {}" ). I'm wondering if this would be one
step making your original suggestion palatable.
I'm also wondering if we should be using the dependency graph
that is effectively coded in Kconfig files to generate the
init calls somehow. Any university students looking for a
very cool and pratical project this year that will make you
famous and pay for your trip to a linux conference next year?
> 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.
Agreed as long as the conversation is about subsystem initialization.
> 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?
Yes. A DEBUG mechanism to record and dump the order when each init
call is started and completed might be one step to satisfy Linus' fear
of not being able to debug the problems.
> 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:
I'm pretty comfortable that explicit dependencies are better.
The question is how to deal with the issues Linus raised and any
other issues folks find in a sane way.
>
> 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);
We just need the "memory_init" function to export a stub in
case it's not actually enabled in the .config file.
>
> 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.
*nod*. I think all of it has be automated. Where automation gets
the dependency info from will be the key to making this work.
hth,
grant
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
