Messages in this thread | | | Subject | Re: Patch to reorder functions in the vmlinux to a defined order | From | (Eric W. Biederman) | Date | Fri, 24 Feb 2006 07:11:25 -0700 |
| |
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/
| |