From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLq8-0001aT-Km for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:50:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdLq5-0004CD-EC for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:50:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdLq5-0004AE-9n for qemu-devel@nongnu.org; Wed, 01 Apr 2015 12:50:01 -0400 Message-ID: <551C21B3.40307@redhat.com> Date: Wed, 01 Apr 2015 18:49:55 +0200 From: Paolo Bonzini 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> <551BE582.1070409@redhat.com> In-Reply-To: <551BE582.1070409@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Eric Blake , Justin Ossevoort , qemu-devel@nongnu.org, Michael Roth -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/04/2015 14:33, Eric Blake wrote: > 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. That's true, and we might take the opportunity to return the number of trimmed bytes separately for each filesystem. Justin, would you like to take a shot at that, or just submit a new version that doesn't include the change to the return value? Thanks, Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVHCGwAAoJEL/70l94x66DuMcH/1Sb013BWNwot+I0jhMEr7jF WgaXQgIAVlxtrzspuE4cXF/TszCie/G1cGlF2oLP+GkJVivbAJFqJYNZcNDfE2Ti OdfhyUCgYMhOYUG81IXIbwXlGca/RhuDW74+B+tEL9dnoissI4l5JWS+k4bWK3On Pgu3gmIcLtQKTxUeDi93K25OAZNJJ9mLmf8CF4FAOUv3C5T4SN5tSkSEqQSB52by zKcM4+cXg5fzYH5OLo6d2SEUqsUHoEVh75VKLb38vAYm3GuNcuVoMEnlSELc3nTo A8Zrmc7swjZXqaZ6iRaXz7seiJ69XrfNWGqY+s0rGZoUK3z8/LwGSpDgmAY3pVQ= =Goct -----END PGP SIGNATURE-----