From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoDhH-0006NF-HX for qemu-devel@nongnu.org; Tue, 11 Nov 2014 10:49:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoDhC-0005Af-Iu for qemu-devel@nongnu.org; Tue, 11 Nov 2014 10:49:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoDhC-0005AZ-5Q for qemu-devel@nongnu.org; Tue, 11 Nov 2014 10:49:30 -0500 Message-ID: <54623003.60606@redhat.com> Date: Tue, 11 Nov 2014 08:49:23 -0700 From: Eric Blake MIME-Version: 1.0 References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-3-git-send-email-mreitz@redhat.com> <54610CCD.8010108@redhat.com> <5461C4C6.8020609@redhat.com> In-Reply-To: <5461C4C6.8020609@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NOUVqbccwrnbk301cMv5XtfQu6cAM6hPG" Subject: Re: [Qemu-devel] [PATCH 02/21] qcow2: Add refcount_width to format-specific info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Lieven , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NOUVqbccwrnbk301cMv5XtfQu6cAM6hPG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2014 01:11 AM, Max Reitz wrote: >>> + .compat =3D g_strdup("0.10"), >>> + .refcount_width =3D s->refcount_bits, >> Hmm - is it really worth displaying a constant? Since the 0.10 format= >> cannot change the width from 16, I'm not sure if it adds anything to t= he >> output to display it. After all, there's other things we omit for the= >> old format when they cannot be altered (such as the state of a lazy >> flag). On the other hand, if it makes your changes to later iotests >> easier for tests that operate on both image formats, I'm not opposed >> to it. >=20 > Yes, I thought about not displaying it. But whereas "corrupt" or "lazy > refcounts" simply do not make sense with compat=3D0.10 images (it's sim= ply > impossible), the refcount width does make sense. It's always 16 bits > (I'm noticing myself how I keep swapping between "bit" and "bits", but = I > just can't help it) but I personally find it interesting enough to > display. I'd be fine with dropping it from compat=3D0.10, though. >=20 > But in retrospect, I'd rather make the other two flags always visible > than now drop this entry. However, not displaying a bool if it's always= > false makes more sense to me than not displaying an integer because it'= s > always constant. >=20 >> If you can make a strong argument for always outputting the constant >> width of 16 for 0.10 formats, then I can live with it, so: >=20 > You decide whether it's strong enough. :-) >=20 > My main argument is "If a bool is not displayed one can assume it to be= > false; if an integer is not displayed which naturally cannot be 0, I > will have no idea what it would be, even if it's constant for that imag= e > version". Sounds fairly convincing :) Add a paragraph like that to the commit message, and I'm sold! >=20 >> Reviewed-by: Eric Blake So looks like you get to keep this. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --NOUVqbccwrnbk301cMv5XtfQu6cAM6hPG 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUYjADAAoJEKeha0olJ0NqATcH/3yZxfaN1ijE0yD/nc+kSbkF cRkmvmYpPNNRfkBsfB8ff+R79WWmqb1u39h2EiVoYt07hDNjAZjRWlzAwY4FNPE7 q3TOFCV9UrBGu2nCycKUjk3BwQmFvGRKi8BjvvRf6UeImKgNF/PXaUh0WV0oUZSU ySbOKAmFejG+YZZp/6qo07rp2vi18JNkT7Adw0kZppBXAtHf0Njhal9RyWCcXRVS w5Et0GwoC1y6PDBLojT0sG/YOpC22fCzLgDl3JkPdaTK2e6Zw09QVqqdIgeFQPz0 YMMS3e0PyGk7Cea4+c15RqL7pFQMqAvjdG1spaIPbNBISi5ZdjZjz10gAYh+mvY= =aUT9 -----END PGP SIGNATURE----- --NOUVqbccwrnbk301cMv5XtfQu6cAM6hPG--