Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

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

Jeremy Fitzhardinge wrote:
> 
> So the bzImage structure is currently:
> 
>    1. old-style boot sector
>    2. old-style boot info, followed by 0xaa55 at the end of the sector
>    3. the HdrS boot param block
>    4. setup.S boot code
>    5. the self-decompressing kernel
> 
> If we make 5 actually an ELF file, containing properly formed Ehdr,
> Phdrs (for all the mappings required), and the actual kernel
> decompressor, relocator and compressed kernel data, then it would be
> easy for the Xen domain builder to find that and use it as a basis for
> loading.  I think it would just require the bzImage boot param block to
> contain an offset of the start of the ELF file.  The contents of the ELF
> file would be in a form where the normal boot code could just jump over
> the ELF headers, directly into the segment data itself.
> 
> ie:
> 
>    1. old-style boot sector
>    2. old-style boot info, followed by 0xaa55 at the end of the sector
>    3. the HdrS boot param block
>    4. setup.S boot code (jumps directly into 5.3)
>    5. 32-bit self-decompressing kernel:
>          1. Ehdr
>          2. Phdrs for all necessary mappings
>          3. decompressor/relocator .text
>          4. compressed kernel data
> 
> Does that sound reasonable?
> 

I don't know if that would break any programs that are currently
bypassing the setup.  The existing setup protocol definitely allows
invoking an entry point which isn't 0x100000 (rather, the 32-bit
entrypoint is defined by code32_start); I'm not sure how Eric's
relocatable kernel patches (2.05 protocol) affect that, mostly because I
haven't seen any boot loaders which actually use it so I can't comment
on what their code looks like.

	-hpa
-
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/