Re: Patch to reorder functions in the vmlinux to a defined order

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

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 23 Feb 2006, Rene Herman wrote:
>> 
>> Okay. I suppose the only other option is to make "physical_start" a variable
>> passed in by the bootloader so that it could make a runtime decision? Ie,
>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>> PHYSICAL_START and this didn't look _too_ bad.

Well the way to accomplish that is to just load the kernel there and
have it sort itself out.  It would take a rev of the boot protocol
to let the bootloader know it was possible though.

> No can do. You'd have to make the kernel relocatable, and do load-time 
> fixups. Very invasive.

Not really. With the linker able to generate the relocations you can
do it outside of most of the kernel where we have the decompressor.  

Relocating a kernel is fundamentally an architecture dependent thing,
relocations can't work at all on x86-64 for example because of the narrow
window of virtual addresses it needs to run at.

I only haven't submitted the patches because I was too busy stabilizing
the reboot path last time I had time to be working in this area.

After I get some sleep I will dust off my patches and see how
it goes.  x86-64 will probably have regressed but...

> It's certainly _possible_, but it's a whole new stage in the boot, one 
> that we've never done before.

It isn't that new.  There has been interest in this area from the
people working on the  kdump stuff for a long you don't require
options under CONFIG_EMBEDDED to build a kernel for capturing a crash
dump. 

CONFIG_PHYSICAL_START was supposed be the simple interim solution
until we could get relocation patches sorted out and merged.

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/