lkml.org 
[lkml]   [2006]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] ELF Relocatable x86 and x86_64 bzImages
    Date
    "Magnus Damm" <magnus.damm@gmail.com> writes:

    > On 8/1/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
    >>
    >> The problem:
    >>
    >> We can't always run the kernel at 1MB or 2MB, and so people who need
    >> different addresses must build multiple kernels. The bzImage format
    >> can't even represent loading a kernel at other than it's default address.
    >> With kexec on panic now starting to be used by distros having a kernel
    >> not running at the default load address is starting to become common.
    >>
    >> The goal of this patch series is to build kernels that are relocatable
    >> at run time, and to extend the bzImage format to make it capable of
    >> expressing a relocatable kernel.
    >
    > Nice work. I'd really like to see support for relocatable kernels in
    > mainline (and kexec-tools!).

    kexec-tools already have initial support for ELF ET_DYN executables.
    Vivek posted a fix a day two ago so I expect that the support
    should be working.

    > 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.

    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.

    By keeping the bzImage processing the relocations we have kept the
    bootloader/kernel interface simple.

    > 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. :)

    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/

    \
     
     \ /
      Last update: 2006-08-02 09:15    [W:4.076 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site