From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5ZuN-0006W2-Aq for qemu-devel@nongnu.org; Wed, 25 May 2016 10:35:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5ZuL-0006hN-10 for qemu-devel@nongnu.org; Wed, 25 May 2016 10:35:38 -0400 References: <1464128732-12667-1-git-send-email-eblake@redhat.com> <1464128732-12667-13-git-send-email-eblake@redhat.com> <20160525142327.GO4815@noname.redhat.com> From: Eric Blake Message-ID: <5745B82F.7000407@redhat.com> Date: Wed, 25 May 2016 08:35:27 -0600 MIME-Version: 1.0 In-Reply-To: <20160525142327.GO4815@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KMUnjrqoJR9f7kr2vqE2WVQtnCM85KPun" Subject: Re: [Qemu-devel] [PATCH 12/13] vmdk: Convert to bdrv_co_pwrite_zeroes() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Fam Zheng , Max Reitz This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KMUnjrqoJR9f7kr2vqE2WVQtnCM85KPun Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/25/2016 08:23 AM, Kevin Wolf wrote: > Am 25.05.2016 um 00:25 hat Eric Blake geschrieben: >> Another step on our continuing quest to switch to byte-based >> interfaces. >> >> Signed-off-by: Eric Blake >> --- >> block/vmdk.c | 13 ++++++------- >> 1 file changed, 6 insertions(+), 7 deletions(-) >> >> diff --git a/block/vmdk.c b/block/vmdk.c >> index 8494d63..284d7a0 100644 >> --- a/block/vmdk.c >> +++ b/block/vmdk.c >> @@ -1704,15 +1704,14 @@ static int vmdk_write_compressed(BlockDriverSt= ate *bs, >> } >> } >> >> -static int coroutine_fn vmdk_co_write_zeroes(BlockDriverState *bs, >> - int64_t sector_num, >> - int nb_sectors, >> - BdrvRequestFlags flags) >> +static int coroutine_fn vmdk_co_pwrite_zeroes(BlockDriverState *bs, >> + int64_t offset, >> + int count, >> + BdrvRequestFlags flags)= >> { >> int ret; >> BDRVVmdkState *s =3D bs->opaque; >> - uint64_t offset =3D sector_num * BDRV_SECTOR_SIZE; >> - uint64_t bytes =3D nb_sectors * BDRV_SECTOR_SIZE; >> + uint64_t bytes =3D count; >=20 > That's an unnecessary variable again. Whether you decide to change it o= r > not: >=20 > Reviewed-by: Kevin Wolf Unnecessary, except that it is 64-bit instead of the block layer interface 32-bit, and I didn't want to have to think too hard about how 'bytes' was used in the rest of the function if I used the narrower type from the get-go. I also think that 'int count' is fishy, because it forces us to think about negative values and placating code sanitizers on undefined shift values; maybe we'd be better with making all byte interfaces use 'uint32_t' (but still limiting ourselves to 0x80000000 or 2G for any power-of-two limit, and 0xffffffff size transactions would not be possible if request_alignment is larger than 1). If we made that switch, I'd still want to keep 0 as a no-op transaction, and not a special case for a 4G transaction. Still, now might be the time to do it= =2E --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --KMUnjrqoJR9f7kr2vqE2WVQtnCM85KPun Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXRbgvAAoJEKeha0olJ0Nq9RsH/0dSeBui14n1eC0GpKYTQZ2/ V4v0E+eHVFubfma0rnKeG7aPr9+jXSiUy7ze17XwrXBWI8LZM0WmMfB2XjDMA/7w +SxDDRJ8QKgdXVh3NiCGIRPLc+rE9gm377jew9DQHVd1ioDH5yMi3fm0cP36YRMx jER5SOvRUctwNZNlaLc8aAzFwmZpB5A5Y4XTHmS7Dm9LvgsYuOg1NWCA063CEjEp wm9IuggWrZ9KbDIGVZPdpJ7FojhUtmAgPy3PyM4uv16slOBHlpWgndk/ZMSKVw+V gDlsnnT2ZifQRj3frfAWr0mVfeH+hhdKo/gyleIUpaxrrUPnQqAvs1jmyq/M02k= =lks7 -----END PGP SIGNATURE----- --KMUnjrqoJR9f7kr2vqE2WVQtnCM85KPun--