Messages in this thread | | | Date | Tue, 02 Oct 2007 18:03:36 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 0/5] Boot protocol changes |
| |
Jeremy Fitzhardinge wrote: > H. Peter Anvin wrote: >> 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. > > It could, or just treat it as a raw binary at 1M+offset to skip the headers.
It would be cleaner to actually parse the ELF; it's only a handful of lines of code (we don't have to support arbitrary placement of sections, obviously, which makes the problem simpler.)
>> 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. > > OK, but that has the same problem as making the payload an ELF file: > 32-bit bootloaders which simply jump to 1M will be jumping into data > rather than code - and I got the impression from taking to Eric at KS > that there are such bootloaders.
Uhm, no it doesn't. Those bootloaders jump to the decompressor, not to the payload. The decompressor interface hasn't changed.
> If that's not an issue, then I still think the payload should be a plain > ELF file (possibly self-decompressing, or just a plain uncompressed > vmlinux, if that's what's desired). Still think making a protected-mode > bootloader do the decompression is the wrong way to go about this; ELF > is enough.
It doesn't have to if it doesn't want to; it only needs to do so if it wants to access the kernel as an ELF. Again, it has the advantage that the ELF is the real vmlinux, no funnies.
-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/
| |