From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5UnF-0002lW-5g for qemu-devel@nongnu.org; Wed, 25 May 2016 05:07:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5UnD-0007wz-UC for qemu-devel@nongnu.org; Wed, 25 May 2016 05:07:57 -0400 Date: Wed, 25 May 2016 11:07:47 +0200 From: Kevin Wolf Message-ID: <20160525090747.GA4815@noname.redhat.com> References: <1464097654-12977-1-git-send-email-kwolf@redhat.com> <1464097654-12977-6-git-send-email-kwolf@redhat.com> <5744F0C9.7050105@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <5744F0C9.7050105@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 05/14] block: Make blk_co_preadv/pwritev() public List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-block@nongnu.org, berto@igalia.com, jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, jsnow@redhat.com --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 25.05.2016 um 02:24 hat Eric Blake geschrieben: > On 05/24/2016 07:47 AM, Kevin Wolf wrote: > > Also add trace points now that the function can be directly called. > >=20 > > Signed-off-by: Kevin Wolf > > --- > > block/block-backend.c | 21 ++++++++++++++------- > > include/sysemu/block-backend.h | 6 ++++++ > > trace-events | 4 ++++ > > 3 files changed, 24 insertions(+), 7 deletions(-) > >=20 >=20 > > @@ -741,11 +742,15 @@ static int blk_check_request(BlockBackend *blk, i= nt64_t sector_num, > > nb_sectors * BDRV_SECTOR_SIZE); > > } > > =20 > > -static int coroutine_fn blk_co_preadv(BlockBackend *blk, int64_t offse= t, > > - unsigned int bytes, QEMUIOVector= *qiov, > > - BdrvRequestFlags flags) > > +int coroutine_fn blk_co_preadv(BlockBackend *blk, int64_t offset, > > + unsigned int bytes, QEMUIOVector *qiov, >=20 > Isn't bytes redundant with qiov->size? Or can qiov be NULL? Should we > assert(!qiov || qiov->size =3D=3D bytes)? It's redundant for reads, as far as I know. I'm not completely sure yet if the redundancy is completely useless; it might help to catch bugs with the qiov initialisation in devices. In any case, if we want to remove bytes from the interface, I think that's a change that should be done consistently across all functions in a series of its own and not hidden in something that is only meant to touch block jobs. > > +int coroutine_fn blk_co_pwritev(BlockBackend *blk, int64_t offset, > > + unsigned int bytes, QEMUIOVector *qiov, > > + BdrvRequestFlags flags) > > { >=20 > Ditto. When doing write_zeroes, do we want qiov =3D=3D NULL, must we alwa= ys > have qiov but just leave qiov->iov[0].base as NULL? Probably worth > documenting as part of making it public. Here it's currently not redundant because we use qiov =3D=3D NULL in some callers. Other callers do the .iov_base =3D NULL, .iov_len =3D bytes thing. Perhaps worth cleaning up, but again, not in this series. Kevin --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXRWtjAAoJEH8JsnLIjy/WO6UP/3Yl59AL1I5+5xyWMgkwVIoj pKQbiBp8l7eyJ2VOg1uAnCLS6bYhWuXzJ9dWRP+DmBDt0vTFkWP9kVUtCuosHDmg RQ3rZ9ojmddFKr/Pu7CvgaQUlXz1f2jZO9m7CxRmUfmqHgqLHr3de3Vfo/72C5au TxOdeoqKXIle9fwB40dU2oh1vkIbVRId92VORisVlC0mD2Xg6xuUdvxCB3k4kGRB ckeMtUs7xPjVHbsbd1qzx0prcRhYgc1N3g+AE+SkTCrVXM/tTMdAFrTlcE+MmHVi hbEB6pbsz9womJgk41cWDqmfeJDQumyS/8eICZovVG2uiurSIKghczjz6D97tfsn QZBfcmT6j36YQHlQVB2BUxR5ponUeKojXJ2xs/599zFiEcsJPBnfmm/u9jiG8imf Cal17y/SMneYqdtyw4fKXwAl02t7G7doMJ8Mv0Cz/s/Qjn4uwFiCmantRArEPxKv 5Sgof76HvHKtgZmyqDNFXZ31nQAAo4FJExkCJ8e0ak9Ji9iaPa86iRVG0HdjCRAc FK0gT6Q/e3GDkjx5w16Rqqsa7rp2lSQf2wd1HDdklvtaBIafwXFqmA4PwzynTf+v R18gd5J1MH1efpI00r+c7gCDNS3PoKk1U9jl6ku44kdkqMmXRZdCgY6rXpIXsTBq nYmUF2D3VdmbRKWpEO9G =sm27 -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--