Hello, Jeff Mahoney wrote:
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 was primarily thinking about percpu areas - how percpu areas are setup and accessed differently on some archs (s390 specifically) and the vmlinux defined symbols which need to be changed if the percpu sections are merged and so on. My worries could be bogus but things are subtle. I think it would be better if we can somehow share the usual module loading code path while skipping time consuming stages.
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.
Yeap, we can surely try to load and initialize earlier than the current initrd. My primary concern is having two separate mechanisms for linking. Module related code including the linker script keeps going through subtle changes, so it's a tad bit scary. Hey, but I have to admit I get scared easily. :-) Thanks. -- tejun -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org