Mailinglist Archive: opensuse-kernel (59 mails)
| < Previous | Next > |
Re: [opensuse-kernel] Moblin kernel merged to FACTORY
- From: Michael Matz <matz@xxxxxxx>
- Date: Thu, 25 Jun 2009 18:00:14 +0200 (CEST)
- Message-id: <Pine.LNX.4.64.0906251743500.29566@xxxxxxxxxxxxx>
Hi,
On Thu, 25 Jun 2009, Jeff Mahoney wrote:
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 :-)
The above option is the only way.
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.
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.
Yes. I see my approach still as static image. In any case if you get
your approach working, all the better.
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx
| < Previous | Next > |