From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ljw8f-0003cW-L5
	for qemu-devel@nongnu.org; Wed, 18 Mar 2009 09:48:57 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ljw8a-0003bA-9J
	for qemu-devel@nongnu.org; Wed, 18 Mar 2009 09:48:56 -0400
Received: from [199.232.76.173] (port=40830 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ljw8a-0003b7-57
	for qemu-devel@nongnu.org; Wed, 18 Mar 2009 09:48:52 -0400
Received: from mx1.redhat.com ([66.187.233.31]:51518)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1Ljw8Z-0006LR-R3
	for qemu-devel@nongnu.org; Wed, 18 Mar 2009 09:48:51 -0400
Message-ID: <49C0FB3B.9070303@redhat.com>
Date: Wed, 18 Mar 2009 15:46:35 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <20090318133633.GA24254@lst.de>
In-Reply-To: <20090318133633.GA24254@lst.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] new scsi-generic abstraction, use SG_IO
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

Christoph Hellwig wrote:
> Okay, I started looking into how to handle scsi-generic I/O in the
> new world order.
>
> I think the best is to use the SG_IO ioctl instead of the read/write
> interface as that allows us to support scsi passthrough on disk/cdrom
> devices, too.  See Hannes patch on the kvm list from August for an
> example.
>
> Now that we always do ioctls we don't need another abstraction than
> bdrv_ioctl for the synchronous requests for now, and for asynchronous
> requests I've added a aio_ioctl abstraction keeping it simple.
>
> Long-term we might want to move the ops to a higher-level abstraction
> and let the low-level code fill out the request header, but I'm lazy
> enough to leave that to the people trying to support scsi-passthrough
> on a non-Linux OS.
>
> Tested lightly by issuing various sg_ commands from sg3-utils in a guest
> to a host CDROM device.
>   

I'm not familiar with SG_IO.  Does it allow the device to dma to/from 
userspace?


-- 
error compiling committee.c: too many arguments to function