From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LiUvh-0006wM-0J for qemu-devel@nongnu.org; Sat, 14 Mar 2009 10:33:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LiUvc-0006v3-5G for qemu-devel@nongnu.org; Sat, 14 Mar 2009 10:33:36 -0400 Received: from [199.232.76.173] (port=59498 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LiUvc-0006ux-0r for qemu-devel@nongnu.org; Sat, 14 Mar 2009 10:33:32 -0400 Received: from verein.lst.de ([213.95.11.210]:55709) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1LiUvb-0007sd-JC for qemu-devel@nongnu.org; Sat, 14 Mar 2009 10:33:31 -0400 Date: Sat, 14 Mar 2009 15:33:27 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH 1/3] Add specialized block driver scsi generic API Message-ID: <20090314143327.GA26791@lst.de> References: <1236862631-22918-1-git-send-email-avi@redhat.com> <1236862631-22918-2-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236862631-22918-2-git-send-email-avi@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 Thu, Mar 12, 2009 at 02:57:09PM +0200, Avi Kivity wrote: > When a scsi device is backed by a scsi generic device instead of an > ordinary host block device, the block API is abused in a couple of annoying > ways: > > - nb_sectors is negative, and specifies a byte count instead of a sector count > - offset is ignored, since scsi-generic is essentially a packet protocol > > This overloading makes hacking the block layer difficult. Remove it by > introducing a new explicit API for scsi-generic devices. The new API > is still backed by the old implementation, but at least the users are > insulated. Getting rid of this is good, I found tons of issues in that area with the I/O path exerciser I wrote last week. Hower the way the new API is designed somewhat gets in the way of my patch series to support Gerd's native preadv/pwritev. One thing I wonder is why we go through the block layer at all for SG. It is actually backed by a char device that doesn't have semantics like a block device at all, given that it can't be seekend and is accessed at byte granularity. We could just go directly to the native Linus syscalls from scsi-generic.c (or a scsi-generic-linux.c if we want some level of abstraction). I'll cook up a patch trying that once I'm back home.