On Tue, 4 Jun 2002, David S. Miller wrote:
> From: Patrick Mochel <mochel@osdl.org>
> Date: Tue, 4 Jun 2002 08:50:11 -0700 (PDT)
>
> On Sun, 2 Jun 2002, David S. Miller wrote:
>
> > It's happening on every platform. It should be done before
> > arch_initcalls actually, but after core_initcalls. I would suggest to
> > rename unused_initcall into postcore_iniscall, then use it for this
> > and sys_bus_init which has the same problem.
>
> Can't it go the other way? Instead of mass-promotion of the setup
> functions, can't we demote the ones that are causing the problems?
>
> There's this middle area between core and subsys, why not
> just be explicit about it's existence?
>
> Short of making the true dependencies describable, I think my
> postcore_initcall solution is fine.
What sense is there in naming it postcore_initcall? What does it tell you
about the intent of the function?
The problem is that if we have arbitrary names with arbitrary priority
levels, people will think they're more important than most, if not all, of
the other initcall users and leapfrog over them into earlier levels. It's
already happened at least once, and I expect to happen more.
The initcall levels are not a means to bypass true dependency resolution.
They're an alternative means to solving some of the dependency problems
without having a ton of #ifdefs and hardcoded, explicit calls to
initialization routines.
We can add more levels and change names. But, we should make them
meaningful for at least two reasons:
- It's obvious to people who are using them what they should use
- It's obvious to someone looking at the code when it gets initialized
That said, how about doing this:
- core
- subsys
- arch
- driver
core initializes the core, as always.
subsys initializes bus and device class subsystems and registers them with
the core.
arch does arch- and platform- specific initlization. arch_initcalls
appear only in arch/ subdirectories, and they happen after
subsys_initcalls.
driver initializes all the device drivers compiled in.
-pat
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:21 EST