From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LWF3J-0001zY-HZ
	for qemu-devel@nongnu.org; Sun, 08 Feb 2009 14:10:49 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LWF3H-0001xS-P5
	for qemu-devel@nongnu.org; Sun, 08 Feb 2009 14:10:48 -0500
Received: from [199.232.76.173] (port=33393 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LWF3H-0001xP-Ko
	for qemu-devel@nongnu.org; Sun, 08 Feb 2009 14:10:47 -0500
Received: from an-out-0708.google.com ([209.85.132.251]:64651)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LWF3H-0006Du-CZ
	for qemu-devel@nongnu.org; Sun, 08 Feb 2009 14:10:47 -0500
Received: by an-out-0708.google.com with SMTP id b6so820630ana.37
	for <qemu-devel@nongnu.org>; Sun, 08 Feb 2009 11:10:46 -0800 (PST)
Message-ID: <498F2E1E.8030605@codemonkey.ws>
Date: Sun, 08 Feb 2009 13:10:22 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1234115947-31622-1-git-send-email-avi@redhat.com>
	<1234115947-31622-4-git-send-email-avi@redhat.com>
In-Reply-To: <1234115947-31622-4-git-send-email-avi@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 3/3] Drop internal
	bdrv_pread()/bdrv_pwrite() APIs
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org

Avi Kivity wrote:
> Now that scsi generic no longer uses bdrv_pread() and bdrv_pwrite(), we can
> drop the corresponding internal APIs, which overlap bdrv_read()/bdrv_write()
> and, being byte oriented, are unnatural for a block device.
>
> Signed-off-by: Avi Kivity <avi@redhat.com>
>
>  int bdrv_truncate(BlockDriverState *bs, int64_t offset)
> diff --git a/block_int.h b/block_int.h
> index e4630f0..cc9966b 100644
> --- a/block_int.h
> +++ b/block_int.h
> @@ -58,10 +58,6 @@ struct BlockDriver {
>      int aiocb_size;
>  
>      const char *protocol_name;
> -    int (*bdrv_pread)(BlockDriverState *bs, int64_t offset,
> -                      uint8_t *buf, int count);
> -    int (*bdrv_pwrite)(BlockDriverState *bs, int64_t offset,
> -                       const uint8_t *buf, int count);
>   

$ grep -l bdrv_pwrite *.c hw/*.c
block.c
block-qcow2.c
block-qcow.c
block-raw-posix.c
block-raw-win32.c
block-vmdk.c
block-vpc.c
savevm.c
hw/scsi-generic.c

So there's a lot of users other than scsi-generic.  Usually, these 
callers are in the block layer to read/write metadata that isn't always 
block aligned.  Some buffer adjustment could fix savevm.c to ensure 
alignment.

These users are now relegated to using emulated pread/pwrite?  Won't 
that have a noticable impact on performance if updating small bits of 
metadata.  For instance, I think updating qcow2 refcounts would look bad 
since you have to read/write the full block to update 4 bytes of data.  
Granted it'll be cached, but...

Regards,

Anthony Liguori
>      int (*bdrv_truncate)(BlockDriverState *bs, int64_t offset);
>      int64_t (*bdrv_getlength)(BlockDriverState *bs);
>      int (*bdrv_write_compressed)(BlockDriverState *bs, int64_t sector_num,
>