Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [RFC] ELF Relocatable x86 and x86_64 bzImages | Date | Wed, 02 Aug 2006 03:59:17 -0600 |
| |
"Magnus Damm" <magnus.damm@gmail.com> writes:
> On 8/2/06, Eric W. Biederman <ebiederm@xmission.com> wrote: >> "Magnus Damm" <magnus.damm@gmail.com> writes: >> > Eric, could you please list the advantages of your run-time relocation >> > code over my incomplete relocate-in-userspace prototype posted to >> > fastboot a few weeks ago? >> >> If you watch an architecture evolve one thing you will notice is that >> the kinds of relocations keep growing. An ever growing list of things >> to for the bootloader to do is a pain. Especially when bootloaders >> generally need to be as simple and as fixed as possible because bootloaders >> are not something you generally want to update. > > I agree that updating bootloaders is something you want to avoid. I'm > not however sure that I would call kexec-tools a bootloader...
On the truly insane possibilities. It is actually possible to load a relocated bzImage. run setup16.S below 1M and have it jump to the kernel at any address below 4G.
>> Beyond that if you look at head.S the code to process the relocations >> (after I have finished post processing them at build time) is 9 instructions. >> Which is absolutely trivial, at least for now. > > Yeah, but the 33 patches are touching more than 9 instructions. =)
True. I at of that is general clean ups to allow the kernel to be relocated though. Not to actually perform the relocation.
> One binary to rule them all... If that is true, is there any simple > way then to extract vmlinux from the bzImage?
Unfortunately the process is a little lossy :(
So that still means you still need the vmlinux to get the debug symbols.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |