From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRi7-0007AF-H6 for qemu-devel@nongnu.org; Mon, 16 Feb 2015 14:52:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNRi4-0003H1-DX for qemu-devel@nongnu.org; Mon, 16 Feb 2015 14:52:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRi4-0003Gs-4Q for qemu-devel@nongnu.org; Mon, 16 Feb 2015 14:52:00 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1GJpxPG011286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 16 Feb 2015 14:51:59 -0500 Message-ID: <54E24A5E.7080605@redhat.com> Date: Mon, 16 Feb 2015 14:51:58 -0500 From: John Snow MIME-Version: 1.0 References: <1423865338-8576-1-git-send-email-jsnow@redhat.com> <1423865338-8576-3-git-send-email-jsnow@redhat.com> <54E249DE.70307@redhat.com> In-Reply-To: <54E249DE.70307@redhat.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v13 02/17] qmp: Ensure consistent granularity type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-devel On 02/16/2015 02:49 PM, Max Reitz wrote: > On 2015-02-13 at 17:08, John Snow wrote: >> We treat this field with a variety of different types everywhere >> in the code. Now it's just uint32_t. >> >> Signed-off-by: John Snow >> --- >> block.c | 11 ++++++----- >> block/mirror.c | 4 ++-- >> include/block/block.h | 2 +- >> include/block/block_int.h | 2 +- >> qapi/block-core.json | 2 +- >> 5 files changed, 11 insertions(+), 10 deletions(-) > > Considering you called this series the "$MY_NAME Fixup issue", I'm > assuming this patch is the response to something I said, maybe that > Coverity might complain about one right-shift of a 64 bit value with the > result stored in a 32 bit integer. If so, that would have been > preventable by assert((x >> 9) <= INT_MAX), so it's not that you would > have to force everything to be 32 bits wide. > > Anyway, I'm fine with either 32 or 64 bits (2 GB maximum granularity > should be good for now): > > Reviewed-by: Max Reitz You mentioned the types weren't /actually/ consistent, and that did actually bother me, so I did try to go out of my way to correct it. I chose uint32_t to match the existing interface for granularity via the drive mirror command, and just whackamole'd the types until they flattened out. Doing it any other way would involve changing other interface options elsewhere, and a 2GiB granularity should seriously be sufficient, considering we currently generally limit it to under 64KiB :)