From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIMPI-0000Bg-1S for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:25:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIMPG-0002Hh-DO for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:25:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIMPF-0002HQ-Tb for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:25:42 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9OFPen1025758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 24 Oct 2011 11:25:40 -0400 Message-ID: <4EA5842F.8050807@redhat.com> Date: Mon, 24 Oct 2011 17:28:47 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1318503845-11473-1-git-send-email-pbonzini@redhat.com> <1318503845-11473-36-git-send-email-pbonzini@redhat.com> In-Reply-To: <1318503845-11473-36-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 35/35] scsi-disk: add scsi-block for device passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org Am 13.10.2011 13:04, schrieb Paolo Bonzini: > scsi-block is a new device that supports device passthrough of Linux > block devices (i.e. /dev/sda, not /dev/sg0). It uses SG_IO for commands > other than I/O commands, and regular AIO read/writes for I/O commands. > Besides being simpler to configure (no mapping required to scsi-generic > device names), this removes the need for a large bounce buffer and, > in the future, will get scatter/gather support for free from scsi-disk. > > Signed-off-by: Paolo Bonzini This doesn't seem to use much of scsi-disk, so what about exporting &scsi_disk_reqops and adding a separate file scsi-block.c? Would make things a bit more symmetrical between scsi-disk and scsi-generic. Or will future patches add code that depends on internal interfaces of scsi-disk? Kevin