From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHFHU-0006TE-OB for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:37:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RHFHP-00017I-2m for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:37:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RHFHO-000178-J3 for qemu-devel@nongnu.org; Fri, 21 Oct 2011 09:36:58 -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 p9LDaubx016725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Oct 2011 09:36:57 -0400 Message-ID: <4EA17576.3090200@redhat.com> Date: Fri, 21 Oct 2011 15:36:54 +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> <4EA16FD3.3060906@redhat.com> <4EA1746F.6030500@redhat.com> In-Reply-To: <4EA1746F.6030500@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 03:32 PM, Kevin Wolf wrote: > 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. Long term, yes. Now, probably not (not until the QOM situation becomes clearer, that is). It would also get you CD recorder passthrough, by composing scsi-generic or scsi-block within the IDE drive. > 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. I agree. On the other hand, the ATAPI code is changed rarely. If it had been kept in sync in the past, I would not have touched it at all. I have never tried using >4.7 GB DVD images, but perhaps they just work and besides burning, they would be the only interesting use case. Paolo