Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751299AbWHBHLp (ORCPT ); Wed, 2 Aug 2006 03:11:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751300AbWHBHLp (ORCPT ); Wed, 2 Aug 2006 03:11:45 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:12499 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1751299AbWHBHLn (ORCPT ); Wed, 2 Aug 2006 03:11:43 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Magnus Damm" Cc: fastboot@osdl.org, linux-kernel@vger.kernel.org, Horms , "Jan Kratochvil" , "H. Peter Anvin" , "Vivek Goyal" , "Linda Wang" Subject: Re: [RFC] ELF Relocatable x86 and x86_64 bzImages References: Date: Wed, 02 Aug 2006 01:09:55 -0600 In-Reply-To: (Magnus Damm's message of "Wed, 2 Aug 2006 15:34:39 +0900") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2750 Lines: 62 "Magnus Damm" writes: > On 8/1/06, Eric W. Biederman 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/