Peter do you plan to update pxelinux or other bootloaders to use the
relocatable kernel feature?
Can we please kill the gosh awful impact lines? They keep breaking my
concentration whenever I try and review these patches. They are
horrible. Something of very minimal significance jumping up and
screaming at me.
The impact lines also fail to capture any of the significant ways I
can easily think of that this patch could cause problems. A little
screw up could cause the kernel to fail to boot for a random portion
of our user base, and the patch as constructed will require changes
to existing bootloaders.
The direction of this patch seems reasonable. The details are broken.
The common case for relocatable kernels today is kdump. A situation
with very minimal memory. In that situation the kernel needs to run
where we put it, modifying the kernel to not run where it gets put
is a problem.
With the code as it is today you can get the exact same behavior
by simply bumping up the minimum alignment to 16MB, and a lot less code
and no changes needed to any bootloaders.
Is your goal to setup a scenario where on small memory systems a bootloader
like pxelinux can support a relocatable kernel and load it a lower
address? If so that seems reasonable.
With that said how about we change the logic to:
if (load_addr == legacy_load_addr) /* 0x100000 */
use config_physical_start
else if aligned
noop
else
/* Crap this is bad align the kernel and hope something works. */
That gets the desired behavior we override bootloaders that are not
smart and taking relocation into account. I am really not comfortable
with having code that will override a bootloader doing something
reasonable.
I expect we will still want to update kexec to be able to take
advantage of loadtime_size (runtime_size seems like the wrong name).
Eric
