From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LirYi-0006ql-Bz for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:43:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LirYd-0006nv-U3 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:43:23 -0400 Received: from [199.232.76.173] (port=46040 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LirYd-0006np-Ny for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:43:19 -0400 Received: from verein.lst.de ([213.95.11.210]:39447) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1LirYd-0000T0-8v for qemu-devel@nongnu.org; Sun, 15 Mar 2009 10:43:19 -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 n2FEhDIF031163 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 15 Mar 2009 15:43:13 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id n2FEhD5M031161 for qemu-devel@nongnu.org; Sun, 15 Mar 2009 15:43:13 +0100 Date: Sun, 15 Mar 2009 15:43:13 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH 1/3] Add specialized block driver scsi generic API Message-ID: <20090315144313.GA30986@lst.de> References: <1236862631-22918-1-git-send-email-avi@redhat.com> <1236862631-22918-2-git-send-email-avi@redhat.com> <20090314143327.GA26791@lst.de> <49BD0892.3060604@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49BD0892.3060604@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 03:54:26PM +0200, Avi Kivity wrote: > >Hower the way the new > >API is designed somewhat gets in the way of my patch series to support > >Gerd's native preadv/pwritev. > > > > > > Can you point out specific issues? The patch series (now posted) makes all aio APIs use iovecs. The current non-iovec based SG API would require some nasty shims allocating nested aiocbs. Or we could just make the sg aio methods fake-ioveced which is the solution I had before your split, always adding a one-element iovec to the scsi-generic request structure. > Using the block layer has the advantage of common setup, statistics, and > management. I agree that the actual data movement is horribly out of > sync with the other format drivers. Yeah, the setup is kinda interwinded with the block layer. I wonder whether the device-tree ideas will help sorting that out. Note that I eventually want to support SG_IO on cdrom devices for burning etc at which point we need to support scsi-generic even if another driver is attached. Note entirely sure how to handle that yet.