Hi, On Thu, 25 Jun 2009, Jeff Mahoney wrote:
In my mind that module lump would not be linked with the static image, but would rather be sort of a mega-module that is loaded implicitely. It would "somehow" be tacked at the end of vmlinux as blob and then loaded with a only mildly extended module loader (basically everything as now, just that you have multiple this_module sections, and with the difference that the initcall order is split and changed)
Yeah, I'd like to be able to relink the static image. It is built with --emit-relocs, so I was hoping that would be enough.
It should be, but nobody is using that option in the hope to be able to link a fully linked executable again, hence there might be interesting bugs lurking. Basically what the linker needs to do is to undo the relocations first (should be possible for most relocs), do the section merging (the linking step) and the apply the relocs again. I wouldn't have expected it to work :-)
This isn't exactly my area of expertise. :) Is there a way to keep this information in the final vmlinux?
The above option is the only way.
I realize it will waste space, but it can be stripped out again when the vmlinuz is made, and the vmlinux image is gzipped when we ship it.
My concern with making it a module lump is that we lose many of the advantages we gain by doing this.
I never bought this argument. I can see how the initcall ordering is an issue, I can see how first having to load an initrd in order to load further modules is an issue. I can't for the life of me figure out why relocation processing of the module loader should in any way be an issue. It's fast if implemented correctly, and I assume the kernel does implement it correctly. All the fancy user-space stuff regarding pre-linking in order to speed up pure app loading with hot caches helps mostly the case where there are many shared libraries to look up symbols in. But here we lookup only in vmlinux and the hypothetical lump.
Yes, we could make it work so that each section is executed in the proper place, but we end up having to do all the back end work for modules anyway, which isn't free.
The solution I'm targeting isn't a "make module loading faster" solution,
I thought the goal of the whole excercise is to have the interesting modules available already long before initrd and in addition that the initorder be optimized by interleaving it with the init of vmlinux proper. The idea to do that was to somehow merge these interesting modules and vmlinux. There is more than one way to implement this merge, at least your current approach, and the module-lump-tacked-to-vmlinux approach.
it's a "make it faster than a static image" solution. If that's possible, it's win-win. We get the advantages of a static image and the advantages of a modular kernel.
Yes. I see my approach still as static image. In any case if you get your approach working, all the better.
Seems to be an internal linker error. What's output of 'readelf -rsW vmlinux | grep boot_gdt_descr' (i.e. what type of reloc and symbol is this)?
c020000c 00a7fb01 R_386_32 c082e116 boot_gdt_descr 1317: c0572676 0 NOTYPE LOCAL DEFAULT 8 boot_gdt_descr 43003: c082e116 0 NOTYPE GLOBAL DEFAULT 38 boot_gdt_descr
That's the problem. Two definitions of the same symbol, once local once global and one relocation which then can't decide anymore which one to choose. Do this: % sed -ie 's/boot_gdt_descr/myown_boot_gdt_descr/g' \ arch/x86/kernel/trampoline_32.S That renames the local version, which can't be referenced from other places anyway. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org