Re: [PATCH v1 1/8] qcow2: introduce compression type feature

[Eric Blake <eblake@redhat.com>]

On 2/27/20 7:59 AM, Vladimir Sementsov-Ogievskiy wrote:

>> Hmm - I think it may be worth a tweak to qcow2.txt to call out:
>>
>> 104: compression_type
>> 105 - 111: padding, must be 0
>>
>> or else call out:
>>
>> 104-111: compression type
>>
>> and just blindly use all 8 bytes for the value even though really only 
>> 1 or two values will ever be defined.  Of course, that moves the byte 
>> in question from 104 to 111, thanks to our big endian encoding, but as 
>> this series is the first one installing a non-zero value in those 8 
>> bytes, and as we just finished documenting that the header length must 
>> be a multiple of 8, there is no real impact - we can make such tweaks 
>> up until the 5.0 release.
> 
> But what is the benefit? We have already documented padding in the spec, 
> and discussed it so much time... What is the problem with padding? And 
> why to add 8 bytes for every new feature which needs only one byte?

Okay, so requiring an 8-byte field is not necessary.  But still, at 
least mentioning padding bytes (that may be assigned meanings later) is 
consistent with the rest of the document (for example, we have padding 
bits documented for the compatible/incompatible/autoclear feature bits), 
and reminds implementers to keep size rounded to a multiple of 8.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org