From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:35356)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SrWBl-0003Da-8g
	for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:29:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SrWBi-0006yy-GZ
	for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:29:21 -0400
Received: from mx1.redhat.com ([209.132.183.28]:34080)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1SrWBi-0006yj-7A
	for qemu-devel@nongnu.org; Wed, 18 Jul 2012 11:29:18 -0400
Message-ID: <5006D60E.2010801@redhat.com>
Date: Wed, 18 Jul 2012 17:28:14 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <4FFA9C30.2070201@linux.vnet.ibm.com>
	<4FFAA0C3.3080703@redhat.com>	<4FFBB7FB.3070303@linux.vnet.ibm.com>
	<4FFBD6F1.90403@redhat.com>
	<20120713091611.GC15503@stefanha-thinkpad.localdomain>
	<4FFFEF8E.5080705@redhat.com> <50000793.2020401@redhat.com>
	<5003CDC6.2040103@linux.vnet.ibm.com> <5003CE8B.20804@redhat.com>
	<500678F7.1030705@linux.vnet.ibm.com> <50067BDB.8000309@redhat.com>
In-Reply-To: <50067BDB.8000309@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu
 block API
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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Michael Tokarev <mjt@tls.msk.ru>, qemu-devel@nongnu.org, =?UTF-8?B?TGx1w61z?= <xscript@gmx.net>, Blue Swirl <blauwirbel@gmail.com>, Stefan Weil <weil@mail.berlios.de>, Hannes Reinecke <hare@suse.de>, Wenchao Xia <xiawenc@linux.vnet.ibm.com>

Am 18.07.2012 11:03, schrieb Paolo Bonzini:
> Let's get things right, and only have open/close:
> 
> int qbdrvs_open(BlockDriverState **bs, const char *filename, int flags,
>                 const char *format_name);
> void qbdrvs_close(BlockDriverState *bs);

What is flags?

Are we really happy with a function that can't provide the features that
-blockdev will give us?

>> int qbdrvs_img_create(const char *filename, const char *fmt,
>>                     const char *base_filename, const char *base_fmt,
>>                     char *options, uint64_t img_size, int flags);

This prototype is totally wrong. It's already not nice that the
signature of some block layer internal function looks like this.
Basically all of the options need to be replaced by something like a
single QDict.

>> /* sync access */
>> int qbdrvs_read(BlockDriverState *bs, int64_t sector_num,
>>               uint8_t *buf, int nb_sectors);
>> int qbdrvs_write(BlockDriverState *bs, int64_t sector_num,
>>                const uint8_t *buf, int nb_sectors);
> 
> I would like to have also a scatter gather API (qbdrvs_readv and
> qbdrvs_writev) taking a "struct iovec *iov, int niov" instead of
> "uint8_t *buf, int nb_sectors".
> 
> flush is missing.

Yes, both very important.

Kevin