Kevin Wolf <kw...@redhat.com> writes: > Am 28.06.2010 12:16, schrieb Christoph Hellwig: >> On Mon, Jun 28, 2010 at 10:24:49AM +0200, Kevin Wolf wrote: >> >>> Am 27.06.2010 11:36, schrieb Christoph Hellwig: >>>> On Sat, Jun 26, 2010 at 04:44:11PM +0200, Markus Armbruster wrote: [...] >>>>> -device usb-storage,drive=foo creates *two* devices: usb-storage itself, >>>>> which serves as SCSI controller, and scsi-disk for the drive. >>>>> usb-storage copies its drive property to scsi-disk. >>>>> >>>>> I don't like this. Each -device should create just one device. >>>> >>>> Indeed. I'd also prefer to get rid of this. Anthony, how hard are the >>>> rules on backwards compatiblity for things like this? >>> >>> How would breaking compatibility help us? For the user a USB MSD is only >>> one device, so requiring two -device parameters sounds wrong.
-device designed to be simple, stupid and straightforward: you get exactly what you asked for, no more, no less. usb-storage breaks this design maxim. >> But it is separate devices. At least the standards compliant usb >> storage devices just are a bride of scsi commands over usb and fit into >> the SAM device model, which makes a difference between initiator, target >> and LUN. So having a different device for the specific target vs the >> initiator port makes a difference. (and yes, we're still totally missing >> support for multiple luns, which would require another level of >> devices). Trying to hide this is not all that useful - not anymore >> useful than hiding it on a "normal" scsi host controller anyway. > > Maybe we need something like composed devices? So when the user asks for > a USB stick, he actually gets all devices that this stick internally > uses? Otherwise it becomes really hard to use -device directly. Could be useful. > I guess the same applies for mainboards, CPUs and probably some more > things, though I don't really know how these are (planned to be) done in > qdev. I'd like to keep -device stupid. If we need "smarter" controls, let's layer them on top.
