From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdHpY-00010z-AH for qemu-devel@nongnu.org; Wed, 01 Apr 2015 08:33:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdHpU-0002Ma-KH for qemu-devel@nongnu.org; Wed, 01 Apr 2015 08:33:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdHpU-0002MA-Fh for qemu-devel@nongnu.org; Wed, 01 Apr 2015 08:33:08 -0400 Message-ID: <551BE582.1070409@redhat.com> Date: Wed, 01 Apr 2015 06:33:06 -0600 From: Eric Blake MIME-Version: 1.0 References: <1427814871-1936-1-git-send-email-justin@quarantainenet.nl> <551AD0C9.6080507@redhat.com> <551AD35F.2020509@redhat.com> <551BA42F.8060104@redhat.com> In-Reply-To: <551BA42F.8060104@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TKOxEI7OV5Mtv1QhDMeqOeCFeXio914RD" Subject: Re: [Qemu-devel] [PATCH] qga/commands-posix: Fix bug in guest-fstrim List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Justin Ossevoort , qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TKOxEI7OV5Mtv1QhDMeqOeCFeXio914RD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/2015 01:54 AM, Paolo Bonzini wrote: >=20 >=20 > On 31/03/2015 19:03, Eric Blake wrote: >>>> >>>> Apart from this, looks good. >> Changing a "return":{} to "return":0 is not backwards-compatible. >=20 > Why not? It's only a minor incompatibility, but a client that hard-codes itself to parsing "returns":0 (that is, expecting a json-number) will fail when talking to an older qemu that provided a json-object instead; while a client that expects a json-object always and can search for a "key":0 integer pair within that object that may or may not be present (we already document that clients MUST be prepared for dictionary members to be optional, but do NOT advise that clients must be prepared for a change between fundamental JSON types). Yes, the backwards-incompatibility is a weak argument, but as my pending series will be requiring all new commands to whitelist a non-dict return, we might as well avoid making this another case for that whitelist. My stronger argument in my other email is that returning a single integer is not much information. Since we have FULL statistics (how much did each file system trim), why not return it all, for the end user to take advantage of if desired? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --TKOxEI7OV5Mtv1QhDMeqOeCFeXio914RD 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVG+WCAAoJEKeha0olJ0Nq7tYH/iTNPufQ1nepxl812rset4sL 4c9Ju6NmfdvpFEycythUxgaNBv/8eOwnARbeg+U5L1pDu6tKLkswbhWD3+mF2noP wXYIZFjNwBV2mc2ILRMxJwCPj14a0eQJ0qqZOAZ2+QdL1X3ChToXAKJRtFsfEjmh +uuRpYxlw+/N/RCG8v6Oc4vVzAWn/qjtg5hjEwj/zqrQxlV9xOc+I2hphMGyjOtc hhRVbdsglg7h5pNYEc2zFiMupFW9kLhcc4Y/sXxnWepXsDMQfYXVuoAS/Rxpa96h x77dk4GMpbAMevJSrVJK2BbM3ecebQhN8S69AOxA1a3QCo+RuGz4dQGZCvkrH3A= =pD6N -----END PGP SIGNATURE----- --TKOxEI7OV5Mtv1QhDMeqOeCFeXio914RD--