-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg KH wrote:
On Tue, Jun 23, 2009 at 12:30:41PM -0400, Jeff Mahoney wrote:
Greg KH 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
On Tue, Jun 23, 2009 at 12:17:17PM -0400, Jeff Mahoney wrote: 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.
Oh ok, I see what you're getting at, but I think the order in the runlevel really only matters if it's slow vs fast. Granularity can't be that important. Runlevels are essentially *free* so we can do things like slow_device_init() if we want. Depending on link order works, but we end up with this mess now where a monolithic beast of a kernel is the "best" option. I was pretty happy leaving the 1.2 kernel behind. :) - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpBEGgACgkQLPWxlyuTD7II7QCgiuUfxn1rAc10R57zj8CwqwbB o0EAnRaF+iS478ONn5g7dzelDK6YhIOz =9Hdr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org