[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH V2 1/8] docs: add compress format extension to q
Re: [Qemu-block] [PATCH V2 1/8] docs: add compress format extension to qcow2 spec
Mon, 10 Jul 2017 09:31:02 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
On 07/10/2017 08:50 AM, Kevin Wolf wrote:
> We have regretted enough things that were defined a bit sloppily just
> for convenience that I'd rather not make this mistake again when we can
> avoid it.
Agreed. Another consideration: defining redundant information is
trickier to maintain because correct implementations have to check that
both points are consistent with one another.
>>>> + 17 - 19: Reserved for future use, must be zero.
>>> We don't need this for now because byte 16 will be the final one in this
>>>> + 20 - 23: extra_data_size
>>>> + Size of compress format specific extra data.
>>>> + For now, as no format specifies extra data,
>>>> + extra_data_size is reserved and should be zero.
>>>> + variable: extra_data
>>>> + Extra data with additional parameters for the compress
>>>> + format, occupying extra_data_size bytes.
>>> extra_data_size isn't necessary because we already have the length of
>>> the header extension, so we know how long the whole thing is.
>>> extra_data isn't necessary because we'll just add new fields at the end
>>> if we want to add something.
>> I was asked to add it altough it is redundant.
> Who asked this, and did they have a good reason for it?
May have been me, or may have been implied by my comments, but I agree
that the overall extension header covers this, so we don't need a
redundant form. So as long as the overall extension header length is
good enough, I'm okay avoiding redundancies.
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Description: OpenPGP digital signature