On 8/2/06, Eric W. Biederman <[email protected]> wrote:
"Magnus Damm" <[email protected]> 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...
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. =)
By keeping the bzImage processing the relocations we have kept the
bootloader/kernel interface simple.
Agreed. I think your patch makes sense.
> One thing I know for sure is that your implementation supports bzImage
> while my only supports relocation of vmlinux files. Are there any
> other uses for relocatable bzImage except kdump?
I can't think of any volume users. A hypervisor that would actually report
the real physical addresses would be a candidate. It's a general purpose
facility so if it is interesting users will show up. Static
relocation has already found another use on x86_64.
There are definitely users of an ELF bzImage beyond the kdump case.
Anything that doesn't have a traditional 16bit BIOS on it. LinuxBIOS,
and Xen, and some others.
Not having to keep track of anything but your bzImage to boot is also
a serious advantage. It's the one binary to rule them all. :)
One binary to rule them all... If that is true, is there any simple
way then to extract vmlinux from the bzImage?
Thanks!
/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
