> 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?
It says "this has to be initialized, but after core initcalls because
it expects core to be setup." That's what "postcore" means. :-)
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.
I added no ifdefs, what are you talking about.
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
How much more meaning do you want than "this requires core to be
setup" That describes a lot to me.
That said, how about doing this:
- core
+- postcore
- subsys
- arch
- driver
core initializes the core, as always.
subsys initializes bus and device class subsystems and registers them with
the core.
But there are things between subsys and core as demonstrated by the
very bug we are trying to fix right now.
You people are blowing this shit WAY out of proportion. Just fix the
bug now and reinplement the initcall hierarchy in a seperate changeset
so people can actually get work done in the 2.5.x tree while you do
that ok?
-
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/