On Tue, Jun 23, 2009 at 12:30:41PM -0400, Jeff Mahoney wrote:
Greg KH wrote:
On Tue, Jun 23, 2009 at 12:17:17PM -0400, Jeff Mahoney wrote:
If you build any code as a module, any of these different levels all change to be the "generic" module_init() call, which runs after all of these 8 levels runs. So you can't work backwards and figure out what level of init call the module really wanted to be run at if you only have a .o file.
And then, within the different init call levels, we call the functions in the order in which they are linked into the kernel, which is driven by the Makefile. If you look at some of the recent changes that were made for "fastboot", we reoder the Makefiles to allow some things to run in parallel before others do (like ata drivers very early, before other drivers in the same run level to take advantage of the slowness of those initialization sequences).
So if you just take the module init sections, and run them some time after all of the above sections run, then you don't get the same speedups that we need. Not having that information in the module is a file size optimization, not a real requirement. We could easily link in the initcall*.init
Greg KH wrote: sections into the modules and then use them for proper ordering when we relink the kernel. Since the initcall sections are consolidated into one during the original link, we would have to add a trampoline initcall to the end of each section to call out to the linked in ones. Since they'd be at the end of the runlevel, the ordering would be preserved.
No, the main issue is the order _within_ the runlevel. Almost every driver is in the "main" device_initcall level. But the ordering within that level matters, and that is only definied by the Makefile order, no symbol resolution or anything else specific we can determine later.
I get that, but if it's safe to run it as a module later why would it matter if it's run at the end of a runlevel instead of the middle of it?
It is "safe", it just isn't "fast", which is one of the main goals here. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org