From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHEuD-0000RP-Ol for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:13:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHEu6-0004Eg-UF for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:13:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHEu6-0004EW-Jy for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:12:54 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9LDCrTM009524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Oct 2011 09:12:53 -0400 Message-ID: <4EA16FD3.3060906@redhat.com> Date: Fri, 21 Oct 2011 15:12:51 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1318503845-11473-1-git-send-email-pbonzini@redhat.com> <1318503845-11473-12-git-send-email-pbonzini@redhat.com> <4EA15AC0.6060708@redhat.com> In-Reply-To: <4EA15AC0.6060708@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/35] scsi-disk: support READ DVD STRUCTURE List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org On 10/21/2011 01:42 PM, Kevin Wolf wrote: > There is only one 'goto fail', all other places have a direct return -1. > It would be good to be consistent. > > Also, as this is mostly a refactored copy from the ATAPI code, I wonder > what our long-term plan is. At which point will we be able to unify what > we're duplicating right now? Can we share some parts even now? That's a tricky question. I think there are three choices: 1) use SCSI as the sole interface exposed by the block layer (with an adaptor). There would be a common implementation of SCSI for SCSI-oblivious devices, and other devices (hdev, sg, iscsi) could just reason in terms of SCSI. You could stack the common implementations (hard drive and CD-ROM) on top of hdev/iscsi or use passthrough. This however is wrong IMHO because some bits of SCSI code really do deal with guest state, for example the tray. 2) let ide-cd create its own SCSI bus and act as an adaptor, similar to USB devices. There would still be duplication for commands that do DMA in multiple steps; I think READ CD is the only one. 3) create a separate API just for the purpose of sharing code between ATAPI and SCSI (your "can we share some parts even now", basically). I think I'm leaning towards (3), but I don't think it makes sense to do it now unless someone is interested in implementing for example CD burning support. However, I'm leaning towards that also because I honestly have no idea how hard (2) would be. Paolo