-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tejun Heo wrote:
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.
If this were a problem, wouldn't we be running into subtle bugs already? The .o files already have the .data.percpu sections regardless of whether it's a module or not. The only special case seems to be that the module code has to parse the percpu section itself and the static kernel uses global variables to delimit the sections. Regardless, I don't think we're really targeting s/390 with this. Really, we're only interested in the x86-based arches.
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. :-)
Indeed. This is something I'm concerned about as well. I haven't yet gotten that part working. I do have a new linker script that doesn't consolidate the initcall sections so we can reuse them and insert new calls. I need to do some more research on the details of relocation. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpCbscACgkQLPWxlyuTD7JftwCfRsyG8OD9Fa1fTL0Y/Mzk+A3a sf0Ani8GHThdRe4wUhJKzsjpZdAi4fqt =hz/M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org