> I've considered it, but there's no way I'll accept more than a small
> number of priorities. And no way in hell that I'll consider real
> dependencies to be acceptable.
>
> What would be acceptable is something like:
> - three priorities: "CPU initialization", "bus initialization" and
> "driver initialization"
> - within each priority, the linking order can be used to sub-prioritize.
Using linking order to prioritize requests smells of making the Makefiles
even more obscure than they are now. We should either forget about priorities
(and use the new init stuff only for things that don't require any explicit
ordering) or introduce real priorities or dependencies.
Also, I'd prefer a mechanism which would be more generic (i.e., which
wouldn't have a fixed number of classes hard-wired in the linker scripts
and so on) and which would leave the actual implementation of init
descriptor storage to arch-dependent code.
It could be done for example this way: Introduce a single section
for init descriptors, define an arch-dependent macro for inserting
an entry to this section and also some macros for walking all init
descriptors. Each descriptor consists of descriptor class (init
function descriptor, command-line argument name etc.), subclass
(for function descriptor it tells whether it's a CPU init, bus init,
driver init or another hook) and some class-dependent arguments.
If you like this way, I'll make a patch tomorrow.
Some day, we could also extend this idea to allow device ID's
to be contained in init list entries, so that the kernel will be
able to match device ID's to driver init functions automatically.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "God is real, unless declared integer."- 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/