From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xh0WJ-0000iM-Og for qemu-devel@nongnu.org; Wed, 22 Oct 2014 14:20:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xh0WE-00052c-Ff for qemu-devel@nongnu.org; Wed, 22 Oct 2014 14:20:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xh0WE-00052U-4l for qemu-devel@nongnu.org; Wed, 22 Oct 2014 14:20:22 -0400 Message-ID: <5447F55B.7080403@redhat.com> Date: Wed, 22 Oct 2014 12:20:11 -0600 From: Eric Blake MIME-Version: 1.0 References: <1413984120-21830-1-git-send-email-pl@kamp.de> <1413984120-21830-2-git-send-email-pl@kamp.de> In-Reply-To: <1413984120-21830-2-git-send-email-pl@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eOn114EtOJ7mRD7eednCe85ITUm1FV5Ch" Subject: Re: [Qemu-devel] [PATCHv2 1/6] block: add accounting for merged requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, armbru@redhat.com, stefanha@redhat.com, mreitz@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eOn114EtOJ7mRD7eednCe85ITUm1FV5Ch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/22/2014 07:21 AM, Peter Lieven wrote: > Signed-off-by: Peter Lieven > Reviewed-by: Max Reitz > --- > block.c | 2 ++ > block/accounting.c | 7 +++++++ > block/qapi.c | 2 ++ > hmp.c | 6 +++++- > include/block/accounting.h | 3 +++ > qapi/block-core.json | 9 ++++++++- > 6 files changed, 27 insertions(+), 2 deletions(-) >=20 > +++ b/qapi/block-core.json > @@ -392,13 +392,20 @@ > # growable sparse files (like qcow2) that are used= on top > # of a physical device. > # > +# @rd_merged: Reserved (Since 2.2) Does this mean it is always output as 0 for now, but may be non-zero at some future date if we figure out how to do merged read requests? Is it even worth adding the field if it has no semantics? We can always add it later when it makes sense, and a client can be smart enough to realize that a missing field is the same as the field being present with value 0 (since that is what clients already have to do for 2.1). I'd feel better with just a bit more documentation or else omitting the field. The rest of the patch is okay, though. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --eOn114EtOJ7mRD7eednCe85ITUm1FV5Ch 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 iQEcBAEBCAAGBQJUR/VbAAoJEKeha0olJ0Nqf4kIAKjzKIXrUAXkFRLdGlbUklCX dsaJvh/r0pTjNGg6KWMouagFbkTx7QcNVTcWxZ5jyrDZxqQcp4WmuGXH9gOVCWmd Bv5bCnUGJ2C5VSk8vFOrP6k526/2XFSMYMHyYZ3ukpLgnTWL+hqGBHsresqPqzGK OwtTrdoW+e3CIOOqcwZnRYkgtz0eKAVF87omuKDTw5WkwX2cfoNltcNGVR+jdrmm jpw5B+C9GN5RIgKrDPw+V2iqZnDNkDLRNXkFBk4hrA3iGzVNVvKQ6ZU9+S21yK6u C/RwSREGnXb2NuGhnKscpz0bgizQ9C4GZVdfdq+RWQk7bmSi6t3mLfOJ/0EpXGE= =olrE -----END PGP SIGNATURE----- --eOn114EtOJ7mRD7eednCe85ITUm1FV5Ch--