qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 08/12] block: Catch attempt to attach multip


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: [PATCH 08/12] block: Catch attempt to attach multiple devices to a blockdev
Date: Wed, 30 Jun 2010 14:13:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4

Am 30.06.2010 13:52, schrieb 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.

I suppose the real question is: What is a device? qemu's internal view
(dozens of devices that communicate with each other) and the user's view
(it's one USB stick/mainboard/...) may differ.

>> 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.

Makes sense. I'm not opposed to having something that deals only with
"atomic devices" or whatever you want to call them.

What users will usually want to have is something that treats an USB
stick as one device, though. So maybe the stupid version should become
-qdev or something and the extended version that is meant for users
should get the easy-to-remember name -device.

Kevin



reply via email to

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