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