From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60173) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLHAe-0000oG-3m for qemu-devel@nongnu.org; Mon, 18 Jan 2016 16:17:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLHAZ-00078R-4f for qemu-devel@nongnu.org; Mon, 18 Jan 2016 16:17:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLHAY-00078N-Sl for qemu-devel@nongnu.org; Mon, 18 Jan 2016 16:16:59 -0500 References: <1452517517-3953-1-git-send-email-vsementsov@virtuozzo.com> <56981C60.9020005@redhat.com> <56982EA9.6030602@redhat.com> <569A4E71.5010004@virtuozzo.com> <569D18CE.5070104@redhat.com> From: Eric Blake Message-ID: <569D5648.6030605@redhat.com> Date: Mon, 18 Jan 2016 14:16:56 -0700 MIME-Version: 1.0 In-Reply-To: <569D18CE.5070104@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UHF8PtsO9pbrQQAxdIdEpO6WE752PnObk" Subject: Re: [Qemu-devel] [PATCH v7] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, den@openvz.org, famz@redhat.com, stefanha@redhat.com, mreitz@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UHF8PtsO9pbrQQAxdIdEpO6WE752PnObk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >> >> >=20 > 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. >=20 > He also felt it would be unusual to stipulate the format of data that w= e > don't even intend to use yet. >=20 > In short, I'm being too proactive. >=20 > 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 worr= y > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --UHF8PtsO9pbrQQAxdIdEpO6WE752PnObk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWnVZIAAoJEKeha0olJ0NqUY0IAIIQM1+tvGNVpmUW2EuM4/5H nkP383gy/fNUqOtoV4KDFWZOtw0qNHWWCsJXXuKOQZ5TMoua7+lyWLUG9pAQY1zE OGMZ6LBNVL6a4f5+Z+LsiGFk/GmmDShtl7iQY03QUKbeqJrOKuLTf/pWBwpv9/Uq I/RMVucGc2h0XDgbL3R71U2rEIRPAgRUi1zHc1BPmG8r3sA5LBVREP5TrHqUGZfa irdWq6SNZ7kFiU2ute6Ze1Ls8SqsxHI4phO77hbVSATDMzU3HLmgsDgJ0wtuAk54 u5YkMqQJak9gDuqYxzfopH6smPYnhKeKktGCg5HDy0MloMCn8SF+GTLwOc3bns4= =0v1G -----END PGP SIGNATURE----- --UHF8PtsO9pbrQQAxdIdEpO6WE752PnObk--