-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tejun Heo wrote:
Hello,
Jeff Mahoney wrote:
Tejun Heo wrote:
Recent kernels produce modules.order which lists the makefile order of modules and is currently used by modprobe to determine which module to load when multiple modules match a device alias. It can take some work but I don't think it'll be too hard to make the fast loaded modules to observe link order. Now this would be really interesting. I was concerned about having multiple .init sections and started doing some work in that area, but I do like the idea of generating the link order via that mechanism instead of just guessing using modprobe.
Have you played around with this at all yet? I realized this morning that my linking attempts were actually done on the compressed image, not with the real vmlinux. The differences are huge: checkout arch/x86/kernel/vmlinux.lds - I'm not sure how to reliably generate a good replacement since it folds sections, etc.
Nope, not yet. I think there can be two different approaches here.
1. Try to create a `static' image from vmlinux and target modules. I doubt this would work very well. There are subtle module specific things which are setup by the module load code and I don't think this will be too easy.
Like what? AFAIK the only difference between a built-in.o and a <module>.ko is that the module has the <module>.mod.o added in which only contains a few sections. The conflicting sections can be renamed or dropped with objcopy before actually linking the static image. I had planned on ignoring the fact that it was a module and adding the static .initcall.init section to each module just like what would happen if it were compiled as a static object. That way, we can just link it in and the initcalls will be in the right section. Since it becomes statically linked, there's no need for the module loading code to be invoked. That's where the fun in ordering comes in, especially because there aren't separate initcall sections in vmlinux.
2. Create an very early initrd thingie which gets loaded by the boot loader and gets unpacked and loaded early during boot. This should be easier but I'm curious how much difference it would make compared to normal initrd if we can make it go faster
Maybe it would be better to think about how to make initrd go faster. If the dynamic relocation time is problem, we can reserve an area in the FIXMAP area and pre-relocate modules and make them a bundle and suck it up into the kernel at once and run initialization for them as usual. It'll be slower than monolithic kernel but hopefullly not by too much.
This runs into the same problem Greg keeps underscoring. The issue is that we want to initialize some things earlier in the boot cycle. In reality, there aren't many of them right now where this will happen - but it's possible to add more runlevels to allow finer granularity when defining the module init. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpBibUACgkQLPWxlyuTD7J7DACgimWd62thkYv43tGVJ95i09fQ 9xUAn37OX4NPbQ1jbJiBMuQmkpWohpUG =mT/+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org