Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"

[ebiederm@xmission.com (Eric W. Biederman)]

Vivek Goyal <vgoyal@in.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.

Eric