qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 11/35] scsi-disk: support READ DVD STRUCTURE


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 11/35] scsi-disk: support READ DVD STRUCTURE
Date: Fri, 21 Oct 2011 15:32:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]