From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCZD3-0003I5-DM for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:25:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCZCw-0007Eu-8E for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:25:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCZCv-0007Ei-Vm for qemu-devel@nongnu.org; Tue, 27 Mar 2012 12:25:18 -0400 Message-ID: <4F71E9EA.1070306@redhat.com> Date: Tue, 27 Mar 2012 10:25:14 -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> In-Reply-To: <1332860615-3047-2-git-send-email-kwolf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC68190A25AD853D9A08EDEA1" 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) --------------enigC68190A25AD853D9A08EDEA1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/27/2012 09:03 AM, Kevin Wolf wrote: > This is the second draft for what I think could be added when we increa= se qcow2's > version number to 3. This includes points that have been made by severa= l people > over the past few months. We're probably not going to implement this ne= xt week, > but I think it's important to get discussions started early, so here it= is. >=20 > +If the version is 3 or higher, the header has the following additional= fields. > +For version 2, the values are assumed to be zero, unless specified oth= erwise > +in the description of a field. > + > + 72 - 79: incompatible_features > + Bitmask of incompatible features. An implementatio= n must > + fail to open an image if an unknown bit is set. > + > + Bit 0: The reference counts in the image file= may be > + inaccurate. Implementations must check= /rebuild > + them if they rely on them. > + > + Bit 1: Enable subclusters. This affects the L= 2 table > + format. > + > + Bits 2-31: Reserved (set to 0) Offsets 72-79 forms 8 bytes, so this should be bits 2-63 are reserved. > + > + 80 - 87: compatible_features > + Bitmask of compatible features. An implementation = can > + safely ignore any unknown bits that are set. > + > + Bits 0-31: Reserved (set to 0) Again, bits 0-63, based on offsets. > + > + 88 - 95: autoclear_features > + Bitmask of auto-clear features. An implementation = may only > + write to an image with unknown auto-clear features= if it > + clears the respective bits from this field first. > + > + Bits 0-31: Reserved (set to 0) And again. > + > + 96 - 99: refcount_bits > + Size of a reference count block entry in bits. For= version 2 > + images, the size is always assumed to be 16 bits. = The size > + must be a power of two. > + [ TODO: Define order in sub-byte sizes ] > + > + 100 - 103: header_length > + Length of the header structure in bytes. For versi= on 2 > + images, the length is always assumed to be 72 byte= s. 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 be padded out to multiples of 8. > +=3D=3D Feature name table =3D=3D > + > +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 l= ater) to > +display a useful error message. > + > +The number of entries in the feature name table is determined by the l= ength of > +the header extension data. Its entries look like this: > + > + Byte 0: Type of feature (select feature bitmap) > + 0: Incompatible feature > + 1: Compatible feature > + 2: Autoclear feature > + > + 1: Bit number within the selected feature bitmap > + > + 2 - 47: Feature name (padded with zeros, but not necessari= ly null > + terminated if it has full length) 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. 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 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC68190A25AD853D9A08EDEA1 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/ iQEcBAEBCAAGBQJPcenqAAoJEKeha0olJ0NqFHUIAKyvHPPVEmPIy2Ryendwyugb 5UEQ/cAC4IC1S2kIWzwfAVexUD1gOe0QYkeshew3E3+FCs2n4T79QTz8sjKpd67O fkK7T5edEWNDOU65Y/jqjz9IGbSJzn31JYb+eajw9clGqRPmZYvAf1uD3yyDkJ3n 5XN+q9GNcaXB2YOHpftHqg7aEgVTJpbMK31h27jp7c9aYZhkILNBT9q7CkRdXjeB 9+d4jxmj2mwa9ny6CBdNRLpxcUwGR+c+5HlKrKKnYAlvjip4+4k0saSEdHhnbdR5 xUCNaME+U/SLTX+QrOJOhGV8s1+gvS2s5ky9jsa8JRuAu4mLqr1nyJJfixvYdDk= =1J8Q -----END PGP SIGNATURE----- --------------enigC68190A25AD853D9A08EDEA1--