From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965440AbXDCKEI (ORCPT ); Tue, 3 Apr 2007 06:04:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965620AbXDCKEI (ORCPT ); Tue, 3 Apr 2007 06:04:08 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:42188 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965440AbXDCKEG (ORCPT ); Tue, 3 Apr 2007 06:04:06 -0400 Date: Tue, 3 Apr 2007 15:33:49 +0530 From: Vivek Goyal To: "Eric W. Biederman" Cc: Andrew Morton , Jurriaan , Helge Hafting , linux-kernel@vger.kernel.org, Magnus Damm , Horms Subject: Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Message-ID: <20070403100349.GA21759@in.ibm.com> Reply-To: vgoyal@in.ibm.com References: <20070331005303.354411f0.akpm@linux-foundation.org> <20070401052932.GA9894@amd64.of.nowhere> <20070331232957.e1c93f19.akpm@linux-foundation.org> <20070402074159.GA13704@in.ibm.com> <20070402094520.GC13704@in.ibm.com> <20070403040152.GA5108@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 02, 2007 at 11:23:17PM -0600, Eric W. Biederman wrote: > Vivek Goyal writes: > > >> I guess at this point the easy case is that we modify /sbin/kexec to support > >> it. And the other bootloaders can come be upgraded if the feature is > >> interesting enough. > >> > >> > On i386, somebody already found an interesting usage of > > CONFIG_PHYSICAL_START > >> > where he was running his kernel above 16MB so that he can maximize on > >> > DMA ZONE. Can't think of any usage for x86_64 at the moment but I think > >> > down the line people might come up with such usages. > >> > >> Agreed. We do have CONFIG_PHYSICAL_ALIGN that can handle that case, > >> although I admit that is a bit of a hack. > >> > > > > Yes, but x86_64 will not have any of those options and only way to run > > kernel will be either use kexec or modify your boot-loader to so that > > it can handle relocatable images. > > True. > > >> > To me, retaining CONFIG_PHYSICAL_START gives added flexibility to the user, > >> > at the expense of reduced simplicity. We should definitely change the type > >> > of vmlinux to ET_DYN but at the same time it might still be worth to retain > >> > CONFIG_PHYSICAL_START option. > >> > >> I think something like CONFIG_PHYSICAL_START currently gives us very > >> little gain, and is hard to use correctly, and there are alternative > >> solutions. So if we can get rid of it, by only inconveniencing users > >> who want load their kernels at a weird address it is worth it. > >> > >> >> I think I can switch the vmlinux header type in about 100 lines or so > >> >> of code. Assuming I can ever get 30 minutes with the appropriate > >> >> kernel. > >> >> > >> > > >> > That would be awesome. Then vmlinux will be relocatable too. (Officially). > >> > >> Yes. For x86_64 I can do this. i386 is more difficult. (Although with > >> a little cleverness we can move the code that processes relocations into > >> vmlinux). > >> > > > > Performing relocations in vmlinux will be interesting. That way i386 vmlinux > > too will become relocatable and only piece of puzzle to solve will be to > > make vmlinux of type ET_DYN. > > Actually making vmlinux have type ET_DYN is the easier piece. Basically > the quick way to do this is to have an arch specific: "cmd_vmlinux__" > like uml does so we can edit things after the make. > > Changing an integer in an ELF header is simple. > > Inserting the code to perform the relocations feels a bit trickier but > we can probably just dump it in head.S like we do on x86_64. We still need > to insert the actual relocations to process though. Which requires all of the > post processing we currently do just called at a slightly different location. Something like what kallsyms does? Read .tmp_vmlinux2, extract and filter relocations, pack them in relocs.S, build reloc.o and relink it back to .tmp_vmlinux2 to make vmlinux. Then arch/i386/kernel/head.S can perform the relocations. But any additiona step of re-linking after final kallsyms information has been generated can potentially spoil kallsyms data? Thanks Vivek