From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lire2-0001I0-AG for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:48:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lirdx-0001G3-1E for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:48:53 -0400 Received: from [199.232.76.173] (port=34120 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lirdw-0001Ft-M3 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:48:48 -0400 Received: from verein.lst.de ([213.95.11.210]:39617) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1Lirdw-0001HE-24 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:48:48 -0400 Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id n2FEmkIF031561 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 15 Mar 2009 15:48:46 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id n2FEmirQ031559 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 15:48:44 +0100 Date: Sun, 15 Mar 2009 15:48:43 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs Message-ID: <20090315144843.GC30986@lst.de> References: <20090314192701.GA3497@lst.de> <20090314192828.GB3717@lst.de> <49BCF79D.8050103@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BCF79D.8050103@redhat.com> 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 On Sun, Mar 15, 2009 at 02:42:05PM +0200, Avi Kivity wrote: > 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, I would not call it hacky an incorrect. And the current dma API certainly won't work due to the layering between the generic virtio layer and virtio-block. > Internally yes, but why should bdrv_* not use QEMUIOVector? That API > isn't very interested in posix. Because it makes life a lot easier. We already pass the length in sector units anyway. While QEMUIOVector could replace instead of currently duplicate it that would mean another translation between byte and sector units at the block level. And then comes the issue of feeding in iovecs - there is the case of iovecs coming from other layers like virtio-blk and the more important one of just creating one-entry static iovecs in many places. These would mean another dynamic allocation and lots of API churn. Keep the QEMUIOVector as a nice abstraction for the memory-managment issues in dma-helper.c but I think as an API for passing data (which doesn't care about how the iovec array is allocated) they aren't very helpful. > > > 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. Sorry, tried to get rid of most of them, but it's a real pain in the ass writing code that way ;-) Guess I need to write me a little obsfucate.awk script before submitting patches..