From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:47756)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S5yQw-0005AC-Ok
	for qemu-devel@nongnu.org; Fri, 09 Mar 2012 06:56:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S5yQq-0008Sm-FB
	for qemu-devel@nongnu.org; Fri, 09 Mar 2012 06:56:30 -0500
Received: from mx1.redhat.com ([209.132.183.28]:1025)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S5yQq-0008SQ-6c
	for qemu-devel@nongnu.org; Fri, 09 Mar 2012 06:56:24 -0500
Message-ID: <4F59F0B8.2010102@redhat.com>
Date: Fri, 09 Mar 2012 12:59:52 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <CA+BHXkKGW-mfKVAw-F5YhsV7EHCObN4Z5TPUJbEaNOQGemTw2g@mail.gmail.com>
	<CAJSP0QUc9TtJXN+pDE9zvSDbv+xR4u_vRPtzKa-WRyaM8j536g@mail.gmail.com>
In-Reply-To: <CAJSP0QUc9TtJXN+pDE9zvSDbv+xR4u_vRPtzKa-WRyaM8j536g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 3/5] block: Virtual Bridges VERDE GOW disk
 image format, legacy GOW version 1 support implementation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Leonardo E. Reiter" <lreiter@vbridges.com>, QEMU Developers Mailing List <qemu-devel@nongnu.org>

Am 09.03.2012 12:42, schrieb Stefan Hajnoczi:
> On Thu, Mar 8, 2012 at 10:15 PM, Leonardo E. Reiter
> <lreiter@vbridges.com> wrote:
>> +#ifndef _WIN32
>> +#include <sys/mman.h>
> 
> I recommend writing this in a platform-independent way using bdrv_*()
> APIs to access the image file.  This has been a requirement for all
> block drivers.  Legacy drivers have been updated too.  The chance of
> merging a new image format that uses platform-specific I/O APIs is low
> IMO.

Let's be clear here: It's not just low, it's zero.

Maybe the qcow2-cache should be generalised so that replacing an mmap in
other image formats becomes easier?

>> +BlockDriver bdrv_gow1 = {
>> +    .format_name    = "gow1",
>> +    .instance_size  = sizeof(gow1_state_t),
>> +    .bdrv_probe     = gow1_probe,
>> +    .bdrv_file_open = gow1_open,
>> +    .bdrv_close     = gow1_close,
>> +    .bdrv_read      = gow1_read,
>> +    .bdrv_write     = gow1_write,
> 
> Please implement .bdrv_co_readv()/.bdrv_co_writev() instead.  They
> work along the same lines - except they allow parallel requests.  If
> you don't want to handle parallel requests you can use a CoMutex to
> serialize these functions.

.bdrv_read/write allow parallel requests as well. The difference is that
bdrv_co_readv/writev is vectored and therefore preferable.

Kevin