Message-ID: <20070403100349.GA21759@in.ibm.com>
Date:	Tue, 3 Apr 2007 15:33:49 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Jurriaan <thunder7@...all.nl>,
	Helge Hafting <helgehaf@...el.hist.no>,
	linux-kernel@...r.kernel.org, Magnus Damm <magnus@...inux.co.jp>,
	Horms <horms@...ge.net.au>
Subject: Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"

On Mon, Apr 02, 2007 at 11:23:17PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@...ibm.com> 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
-
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