Messages in this thread | | | Date | Wed, 4 Aug 1999 21:43:27 +0200 | From | Martin Mares <> | Subject | Re: More linker magic.. |
| |
Hello,
> 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/
| |