> Ok, I finally did what I've wanted to do for a _loong_ time: get rid of
> the horrible #ifdef CONFIG_XXXX mess in init/main.c.
>
> Instead, any driver, filesystem or other entity can just register a kernel
> command line string and/or a initialization function that will be executed
> by using a magic section in the kernel linkage. So there is no need to
> touch a common file to add a new driver or a architecture-specific kernel
> command line entry.
>
> I've fixed up a few of the old command lines and initialization functions,
> but I'm hoping that driver writers can re-instate their own setup
> functions rather than me trying to fix up them all by hand. For that
> reason there is now a pre-patch-2.3.13-3 on ftp.kernel.org under
> "testing".
>
> Go wild.
Great stuff.
Would it make sense to add a "priority" argument to __initcall ?
This would allow to express simple dependencies between modules. Of course
this could be emulated by immediate functions that do the traditional manual
initialization.
When I have a large independent subsystem which has lots of modules,
like the networking queue disciplines, all dependent on some other
subsystem(s) to be initialized first (networking, queueing manager):
this would require the old #ifdef mess again with the middle function
that enforces ordering. Using priorities would be much cleaner.
Expressing the priority via file ordering in the Makefile would be
flaky IMHO, and probably cause for subtle bugs.
A central include file that assigns init priorities to well known
subsystems would be better IMHO.
The standard[1] linker cannot sort constructors, but system startup
is not performance critical, so it is reasonable to sort the init
table at runtime.
Would you accept a patch for that ?
-Andi
[1] Some newer binutils versions have support for it, but it is probably
better to not make the kernel dependent on them yet.
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/