From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LipfV-00042e-NA for qemu-devel@nongnu.org; Sun, 15 Mar 2009 08:42:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LipfR-0003zq-AB for qemu-devel@nongnu.org; Sun, 15 Mar 2009 08:42:17 -0400 Received: from [199.232.76.173] (port=58392 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LipfR-0003zn-56 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 08:42:13 -0400 Received: from mx2.redhat.com ([66.187.237.31]:53948) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LipfQ-0001d5-CT for qemu-devel@nongnu.org; Sun, 15 Mar 2009 08:42:12 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2FCgAui014435 for ; Sun, 15 Mar 2009 08:42:11 -0400 Message-ID: <49BCF79D.8050103@redhat.com> Date: Sun, 15 Mar 2009 14:42:05 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs References: <20090314192701.GA3497@lst.de> <20090314192828.GB3717@lst.de> In-Reply-To: <20090314192828.GB3717@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Christoph Hellwig wrote: > QEMUIOVector is a useful helper for the dma-helper.c internals but for a generic > block API it's more of hindrance. Some top-level consumers like virtio-blk > already have the plain iovec and segment number at hand and can pass it down > directly, and for those that just have a single element and need to fake up > a vector the plain iovec also is a lot easier. > virtio gets its iovecs through a hacky (and incorrect, try >=4G) method. IMO virtio should be fixed to use the dma api, at which point it will start to use QEMUIOVector anyway, > Last but not leas we want to push down vectored I/O to the lowest level, > and if posix-aio-compat.c wants to stay somewhat true to it's goal of > beeing like an ehanced posix AIO API it should stick to posix types. > Internally yes, but why should bdrv_* not use QEMUIOVector? That API isn't very interested in posix. > static BlockDriverAIOCB *bdrv_aio_rw_vector(BlockDriverState *bs, > int64_t sector_num, > - QEMUIOVector *iov, > + struct iovec *iov, > + int nr_iov, > int nb_sectors, > BlockDriverCompletionFunc *cb, > void *opaque, > Note qemu never uses tabs in source code. -- error compiling committee.c: too many arguments to function