On Tue, Jun 23, 2009 at 01:03:48PM +0200, Michael Matz wrote:
Hi,
On Mon, 22 Jun 2009, Greg KH wrote:
But that's really just to address dependencies, right? I don't intend to load the modules at the same runlevel where they would have run if normally compiled statically. If we load the linked module after the usual static parts have initialized, then we'll still observe the dependencies.
No, it's to tell the kernel exactly when to initialize the code at what part during the init level processing, and link order matters.
"exactly when to initialize the code" == "addresses dependencies", isn't it?
No, see below for details.
Actually, in thinking about it some more, I don't think this is going to work properly for the "fastboot" stuff that we really need. Here's why:
- When drivers are build into the kernel, they are initialized in the order in which the Makefile places them, and we build them in pretty early. This allows the drivers to start up, and do some async stuff while the rest of the kernel initializes.
Excuse me for not being up-to-date wrt. the kernel anymore, but isn't this done via the .init sections?
Yes it is, but order within the .init sections matter.
- If you somehow "link" the modules into the built kernel, you will have to set up a mechanism to call the module_init() calls. The only safe way to do that is at the end of the init cycle. So any async processing that could have happened, will not, as these drivers will be the last things in the boot process now, instead of very early like they used to be.
... Because if it is, then linking modules into the built kernel after the fact isn't going to change this principle. You still have a .initcall section (well, two of them, one for the built kernel, one for the module lump) which the kernel proper would iterate over very early (after determining existence of the second initcall table).
We really have 8 different levels of init calls in the kernel these days: #define pure_initcall(fn) __define_initcall("0",fn,0) #define core_initcall(fn) __define_initcall("1",fn,1) #define core_initcall_sync(fn) __define_initcall("1s",fn,1s) #define postcore_initcall(fn) __define_initcall("2",fn,2) #define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s) #define arch_initcall(fn) __define_initcall("3",fn,3) #define arch_initcall_sync(fn) __define_initcall("3s",fn,3s) #define subsys_initcall(fn) __define_initcall("4",fn,4) #define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s) #define fs_initcall(fn) __define_initcall("5",fn,5) #define fs_initcall_sync(fn) __define_initcall("5s",fn,5s) #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs) #define device_initcall(fn) __define_initcall("6",fn,6) #define device_initcall_sync(fn) __define_initcall("6s",fn,6s) #define late_initcall(fn) __define_initcall("7",fn,7) #define late_initcall_sync(fn) __define_initcall("7s",fn,7s) 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. If you look at the startup boot graphs, this is seen quite well, with the ATA drives taking a long time to startup, all the while the rest of the kernel is running along, initalizing other things. If you move the ata drivers to the end of the init sequence, then the whole kernel waits for that hardware to startup, wasting almost a full second. Remember, we are talking about a whole boot time of the kernel to be less than a second right now, so optimizations like this are essencial to get there. hope this helps explain things a bit better, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org