Messages in this thread | | | Date | Tue, 02 Oct 2007 17:43:44 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 0/5] Boot protocol changes |
| |
Jeremy Fitzhardinge wrote: > H. Peter Anvin wrote: >>> This series looks like a good start for Xen, but we still need to work >>> out where to stash the metadata which normally lives in ELF notes. >>> Using ELF is convenient for Xen because it lets a large chunk of domain >>> builder code be reused; on the other hand, loading a plain bzImage is >>> pretty simple, so maybe it isn't such a big deal. >>> >>> HPA, Eric: if we don't go the "embed ELF" path, where's a good >>> backwards-compatible place to stash the note data? If we do go with >>> "embed ELF", how should we go about doing it? Arrange to put the ELF >>> headers before the 1M mark? >>> >> This sounds like another good reason to do the ELF image as the >> postcompression image. The interface to the embedded compression >> routine is then unchanged, and we get the "full vmlinux" with any >> notes that belongs there. >> >> I'll try to get an implementation of that done -- it really shouldn't >> be very hard. > > Please explain what you're proposing again, because my memory of your > plan from last time wouldn't help in this case. Are you proposing that > the bzImage contains compressed data that its expecting the bootloader > to decompress? Won't that completely break backwards compatibility? If > we don't care about backwards compatibility with old bootloaders, then > it doesn't matter what we do one way or the other. >
No, not at all.
I'm proposing that the existing bzImage format be retained, but that the payload of the decompressor (already a gzip file) simply be vmlinux.gz -- i.e. a gzip compressed ELF file, notes and all. A pointer in the header will point to the offset of the payload (this is new, obviously.)
The decompression stub is adjusted to expect an ELF image, instead of a raw binary.
Existing bootloaders (16- or 32-bit) simply load the bzImage the way they do now; new bootloaders have the option of accessing the vmlinux.gz directly if they either want to load it themselves or want to examine the notes.
-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/
| |