Re: [Qemu-devel] Re: [PATCH 08/12] block: Catch attempt to attach multiple devices to a blockdev

[Markus Armbruster]

Kevin Wolf <address@hidden> 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.