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).