[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aec7e5c30608012334y42e947e6ge935e5d866f78c84@mail.gmail.com>
Date: Wed, 2 Aug 2006 15:34:39 +0900
From: "Magnus Damm" <magnus.damm@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: fastboot@...l.org, linux-kernel@...r.kernel.org,
Horms <horms@...ge.net.au>,
"Jan Kratochvil" <lace@...kratochvil.net>,
"H. Peter Anvin" <hpa@...or.com>,
"Vivek Goyal" <vgoyal@...ibm.com>, "Linda Wang" <lwang@...hat.com>
Subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages
On 8/1/06, Eric W. Biederman <ebiederm@...ssion.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!).
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?
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?
Thanks!
/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists