From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS5fX-0001i3-Lh for qemu-devel@nongnu.org; Mon, 24 Mar 2014 10:16:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WS5fO-0000Qh-MI for qemu-devel@nongnu.org; Mon, 24 Mar 2014 10:16:03 -0400 Received: from 28-113-190-109.dsl.ovh.fr ([109.190.113.28]:42348 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WS5fO-0000KS-CK for qemu-devel@nongnu.org; Mon, 24 Mar 2014 10:15:54 -0400 Date: Mon, 24 Mar 2014 15:15:28 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140324141528.GE3071@irqsave.net> References: <1394232956-27852-1-git-send-email-mreitz@redhat.com> <1394232956-27852-8-git-send-email-mreitz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1394232956-27852-8-git-send-email-mreitz@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 07/12] block/json: Add bdrv_co_get_block_status() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , =?iso-8859-1?Q?Beno=EEt?= Canet , pl@kamp.de, qemu-devel@nongnu.org, Stefan Hajnoczi The Friday 07 Mar 2014 =E0 23:55:51 (+0100), Max Reitz wrote : > Implement this function in the same way as raw_bsd does: Acknowledge > that this is a passthrough driver (always return BDRV_BLOCK_OFFSET_VALI= D > and BDRV_BLOCK_DATA and derive the offset directly from the sector > index) and add BDRV_BLOCK_RAW to the returned value. >=20 > Signed-off-by: Max Reitz > --- > block/json.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) >=20 > diff --git a/block/json.c b/block/json.c > index e4cdb68..966a5f5 100644 > --- a/block/json.c > +++ b/block/json.c > @@ -110,6 +110,15 @@ static coroutine_fn int json_co_write_zeroes(Block= DriverState *bs, > return bdrv_co_write_zeroes(bs->file, sector_num, nb_sectors, flag= s); > } > =20 > +static coroutine_fn int64_t json_co_get_block_status(BlockDriverState = *bs, > + int64_t sector_nu= m, > + int nb_sectors, i= nt *pnum) > +{ > + *pnum =3D nb_sectors; > + return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_DATA = | > + (sector_num << BDRV_SECTOR_BITS); > +} > + > static void json_invalidate_cache(BlockDriverState *bs) > { > return bdrv_invalidate_cache(bs->file); > @@ -156,6 +165,7 @@ static BlockDriver bdrv_json =3D { > .bdrv_aio_discard =3D json_aio_discard, > =20 > .bdrv_co_write_zeroes =3D json_co_write_zeroes, > + .bdrv_co_get_block_status =3D json_co_get_block_status, > =20 > .bdrv_invalidate_cache =3D json_invalidate_cache, > =20 > --=20 > 1.9.0 >=20 If this filter is stacked on top of qcow2 even the simple BDRV_BLOCK_RAW = feel weird. I think the best thing we can do is to ask to Peter Lieven if this code h= as the intended meaning in a block filter. Peter:=20 You wrote the inspiration for this code in raw-posix.c. What do you think of this piece of code designed to be stacked as a block= filter on top of regular block driver (qcow2 etc) ? Does it makes sense ? Or would it be better to forward the call to the lo= wer level ? Best regards Beno=EEt