Re: [Qemu-devel] [PATCH v7] spec: add qcow2 bitmaps extension specification

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]

On 01/18/2016 09:54 AM, John Snow wrote:

>> Please, let's decide finally about extra data, than I'll reroll it and,
>> I hope, it will be committed, to make it possible to continue work on
>> persistence series. About extra data, I'm ready to accept any variant,
>> strictly defining, what software should do with unknown extra data.
>>
>>
> 
> I discussed this with Eric Blake on IRC briefly, and I mentioned I was
> concerned that we didn't specify a format at all for the extra data.
> Eric felt that it was not unusual to leave a space for future expansion
> and that as we haven't used it yet, we don't need to solidify it.
> 
> He also felt it would be unusual to stipulate the format of data that we
> don't even intend to use yet.
> 
> In short, I'm being too proactive.
> 
> A commit message mention that, should anyone wish to expand the
> type-specific data in the future that adding a 2-byte version as the
> first field in extra data would probably be sufficient, and we can worry
> about the spec wording later. It is fine to assume for now that if
> extra_data_size is 0 that the version/format of the data is "v0" and
> that does not limit our future expansion.

Or put another way:

I'm just fine if our initial implementation provides sufficient
information for us to completely parse the file even when the file is
generated by a newer qemu (we have a length, so we know how far to skip
to find the next entry), while at the same time throwing up our hands if
the length is non-zero (we won't read the bitmap at all, because we
don't know if the non-zero extra_data contains instructions that would
change how to interpret the data) or even prevent writes (if the bitmap
entry is marked automatic, we must refuse any write that would requiring
an update to the bitmap because we don't know how to write to a bitmap
while correctly preserving semantics of those extra_data bytes).  We
have enough room for future extension, and that's good enough for now;
the commit message can document that we thought about the future,
without having to actually nail down in the spec what the future will
actually do.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]