On Mon, Jun 22, 2009 at 02:15:13PM -0400, Jeff Mahoney wrote:
Greg KH wrote:
On Mon, Jun 22, 2009 at 01:38:01PM -0400, Jeff Mahoney wrote:
Greg KH wrote:
On Mon, Jun 22, 2009 at 09:12:14AM +0200, Hannes Reinecke wrote:
I'm still not a fan of this, but in the absence of the ability to link in modules at install time, I guess the gains outweigh the drawbacks.
Why don't we do something about it?
I've already spent some thoughts about it, and come up with two possibilities:
- Link in modules during initrd run. Shouldn't be too hard, after all that's what the kernel does nowadays during building anyway. So just some linker magic and you're done. Drawback is that you'd need an uncompressed kernel to start with, so I'm not sure it's the right way to go - Implement something like the 'kexec-cache' from Max OS-X. OS-X has a 'kexec-cache', which allow to preload some kernel modules during boot. Implementing a similar thing on Linux we could just stuff the preloaded modules into a blob and load this as an additional initrd image. Then we could just call the ->init calls and everything would be dandy. Or that's the hope. Big problem is that you need the .c files because you can have different code paths built in the file depending on if you are built to be a module or built into the kernel due to #ifdefs :( I know they exist, but what are the valid use cases for doing that and do we need to worry about a lot of them? It seems like the cases can be broken down into a few categories:
* print something * change a description string * optimize away things that aren't required when statically linked
Also: - initialize something at a different run level
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. 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. - 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. Now if you could figure out how to insert them into the link order in the boot process in the same sequence as if they were built in, that would be very nice, but I don't see how that would be possible. So, by adding the modules on to the kernel image, all we would save would be the module load time, which while not insignificant, is not sufficient for the boot times we are needing to achieve here. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org