From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHFAB-0004Q0-7B for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:29:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHFA7-00084t-6D for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:29:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHFA6-00084p-Sw for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:29:27 -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 p9LDTPbs015110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Oct 2011 09:29:26 -0400 Message-ID: <4EA1746F.6030500@redhat.com> Date: Fri, 21 Oct 2011 15:32:31 +0200 From: Kevin Wolf 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> <4EA16FD3.3060906@redhat.com> In-Reply-To: <4EA16FD3.3060906@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 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: Paolo Bonzini Cc: qemu-devel@nongnu.org Am 21.10.2011 15:12, schrieb Paolo Bonzini: > 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. Which gives me the impression that your feeling is (as well as mine) that (2) would give us the nicer result and is probably the Right Thing to do long-term. Though at the same time I agree that I don't have an idea of how hard this would be and if it would be worth the effort. And with the current qdev that doesn't allow device composition it might even get really ugly. It's a hard question, but ignoring it is probably not a solution. Kevin