H. Peter Anvin wrote:
quoted text
>> 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.

    J
-
unsubscribe notice
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/