Re: another RFC patch: bzImage with ELF payload

["H. Peter Anvin" <hpa@zytor.com>]

Jeremy Fitzhardinge wrote:
> OK, here's another go-around.  This patch leaves the bzImage itself
> unmodified, but it changes the payload into an ELF file.  That is, the
> 32-bit decompression/relocation+compressed kernel is now a properly
> formed ELF file.
> 
> One thing that fell out of this is that code32_start end up being a
> pointer to the ELF header rather than an entrypoint.  Rather than
> reproducing Vivek's (?) hack of making the ELF header itself executable,
> I changed the 16-bit code to check for an ELF magic number at
> code32_start and use the e_entry to get the actual entrypoint.  This
> seems like approximately the right way of doing this, but I'm not sure
> how we want to formalize it.  It's certainly easier than trying to
> extract the payload's entry address and copying it to code32_start in
> the boot_params block, and we need a pointer to the ELF file itself anyway.
> 

No, that breaks any boot loader that uses the boot loader hook
mechanism.  That's definitely broken.

Either way, I still believe that this should be done at the other end of
the decompression chain.  Give out the information about *how the kernel
will be executed*, not about the intermediate, transient step.

	-hpa