Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750721AbWHBKBG (ORCPT ); Wed, 2 Aug 2006 06:01:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750732AbWHBKBG (ORCPT ); Wed, 2 Aug 2006 06:01:06 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:11445 "EHLO ebiederm.dsl.xmission.com") by vger.kernel.org with ESMTP id S1750721AbWHBKBE (ORCPT ); Wed, 2 Aug 2006 06:01:04 -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 03:59:17 -0600 In-Reply-To: (Magnus Damm's message of "Wed, 2 Aug 2006 17:34:44 +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: 1891 Lines: 45 "Magnus Damm" writes: > On 8/2/06, Eric W. Biederman wrote: >> "Magnus Damm" 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/