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
