-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
Now that should be fixed up properly by doing the correct macro, but I have seen it enough that it is common.
A lot of the stupid things are in ISA drivers.
Agreed, and we aren't building ISA drivers for "real" systems anymore, thankfully :)
I do see one case in usbcore, but even that seems like it should always allow usbcore.nousb and enable nousb for ifndef MODULE.
I do see your point that making assumptions like this could be fragile.
Yeah, it's the odd-cases that I worry about here.
Or perhaps a different solution would be to whitelist modules which are known to be safe. Given the number of modules we want to typically link in, this shouldn't be a long list. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAko/yjEACgkQLPWxlyuTD7KCsACeO3Lfr+zhj8dByRZ+E0LJpeKL ROUAoIErXMCBntEysg16w0knmOl/KIkr =Y0Yw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org