From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEjtT-0005ha-PL for qemu-devel@nongnu.org; Mon, 02 Apr 2012 12:14:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SEjtO-0003Fe-Bu for qemu-devel@nongnu.org; Mon, 02 Apr 2012 12:14:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:15204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEjtO-0003FX-3J for qemu-devel@nongnu.org; Mon, 02 Apr 2012 12:14:06 -0400 Message-ID: <4F79D04A.7020305@redhat.com> Date: Mon, 02 Apr 2012 10:14:02 -0600 From: Eric Blake MIME-Version: 1.0 References: <1332860615-3047-1-git-send-email-kwolf@redhat.com> <1332860615-3047-2-git-send-email-kwolf@redhat.com> <4F71E9EA.1070306@redhat.com> <4F7978CB.9040005@redhat.com> In-Reply-To: <4F7978CB.9040005@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig796E346BFF8076804161F029" Subject: Re: [Qemu-devel] [RFC PATCH 01/16] Specification for qcow2 version 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: stefanha@gmail.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig796E346BFF8076804161F029 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/02/2012 04:00 AM, Kevin Wolf wrote: > Am 27.03.2012 18:25, schrieb Eric Blake: >> On 03/27/2012 09:03 AM, Kevin Wolf wrote: >>> This is the second draft for what I think could be added when we incr= ease qcow2's >>> version number to 3. This includes points that have been made by seve= ral people >>> over the past few months. We're probably not going to implement this = next week, >>> but I think it's important to get discussions started early, so here = it is. >>> >> >>> + >>> + 100 - 103: header_length >>> + Length of the header structure in bytes. For ver= sion 2 >>> + images, the length is always assumed to be 72 by= tes. >> >> Might be a good idea to require this to be a multiple of 8, since both= >> 72 and 104 qualify, and since header extensions are also required to b= e >> padded out to multiples of 8. >=20 > Do you see any arguments for padding to multiples of 8 besides > consistency? Yes - void* on some platforms is 8 bytes, and having everything guarantee 8-byte alignment can make processing of headers more efficient when you are reading things on natural alignments. Furthermore, guaranteeing 8-byte alignment buys us three bits that are always 0 but which can later be converted to bit flags for future extensions; by requiring 8-byte alignment, older parsers will reject the new bit flags (because it looks like a non-multiple-of-8 length), while newer parsers will know that they are bit flags and what those flags mean, as well as know to mask out those bits when computing aligned size of the header. > If I did the format from scratch, without having to pay > attention to compatibility, I would drop the requirement even for heade= r > extensions as I don't see what it buys us. It's always hard to predict what future extensions will look like, but I argue in return that it is easier to start out strict and relax things in the future than it is to start relaxed and then wish we could tighten it up. >=20 > Consistency is important and certainly good enough to make me unsure > about this, but I don't like artificial restrictions either. If we had > another good reason, it would be easier for me to decide. If sizeof(void*) for natural alignment and the possibility of extension to 3 bit flags per extension header don't convince you, then I won't insi= st. >> Semantic nit: The NUL character is all zeros; it is one byte in all >> unibyte and multi-byte encodings, and the NUL wide character is the >> all-zero wchar_t value; while 'null' refers to a pointer to nowhere. >> Saying a string is null terminated is wrong, because you don't have a = 4- >> or 8-byte NULL pointer at the end of the string, just a one-byte NUL >> character. Therefore, strings are nul-terminated, not null-terminated= =2E >=20 > "null-terminated" is much more common. Google and Wikipedia are the > proof. ;-) Unfortunately true :) But I'll quit bothering you about this one, as I'm swimming against the current on that one. >=20 >> Is this extension capped at 48 bytes, or it is a repeating table of as= >> many 48-byte multiples as necessary to represent each feature name? >=20 > The latter. All feature names are in a single table in a single header > extensions. Any suggestion how to clarify this? Would something like > "There shall be at most one feature name table header extension in an > image" be clear enough? Maybe: A feature name table is an optional header extension that contains the name for features used by the image. It can be used by applications that don't know the respective feature (e.g. because the feature was introduced only later) to display a useful error message. There can be at most one feature name table, and within that table, each feature name may only appear once. The number of entries (n) in the feature name table is determined by the length of the header extension data. Its entries look like this: Byte 48*n + 0: Type of feature (select feature bitmap) 0: Incompatible feature 1: Compatible feature 2: Autoclear feature 48*n + 1: Bit number within the selected feature bitmap 48*n + 2 to 47: Feature name (padded with zeros, but not necessarily null terminated if it has full length) Do we also need to clarify that at offsets 48*n + 1, the bit number must be 0-63 (and thus the upper two bits must be 0)? Do we also want to enforce that the table is sorted (that is, given the tuple in bytes 0 and 1 of each entry, we want to require that entry <0,0> appears before <0,1> appears before <1,0>)? --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig796E346BFF8076804161F029 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPedBKAAoJEKeha0olJ0NqMXMIAI2sYZrR95OsEfcDQmbpAB4E GdelMZM8HTMJoH6Pc4WV78dtOj+F0x5C9SURHeu6k+Q5gYW3BStXEFZn5gCM6Z47 NXkrEYcY6gCWQ8tpFCA+WE0M6XG8cVN+o2jlp0Vvk18eyZcaShPDtoz6z/3QkhET JREd+Av7z2CbX3j+5dHhYAq+8hzr9hV2SzmhtenIM5IvfqPC7CLnit8reEyEOPsT kiZvXhuVCaQNosqQ04LvWuNYQzu6jTVwfe7PeBYb304LrLF6oOyKF9t7npQR11V2 fPW1s+rqMy4K4WvGBvVlBOE+iGFOJWJFS7OqxusRtBqAwDRyzYh0dkwku0sQBV4= =UphT -----END PGP SIGNATURE----- --------------enig796E346BFF8076804161F029--