[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP do
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs |
Date: |
Wed, 16 Jun 2010 13:02:23 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Avi Kivity <address@hidden> writes:
> On 06/15/2010 05:54 PM, Markus Armbruster wrote:
>> Avi Kivity<address@hidden> writes:
>>
>>
>>> On 06/15/2010 04:27 PM, Markus Armbruster wrote:
>>>
>>>>
>>>>> I'm only talking about the interface, not the implementation.
>>>>> Internal design details shouldn't be exposed.
>>>>>
>>>>> For the implementation, I imagine you can create an empty blockdev
>>>>> during guest device creation and treat blockdev_add/blockdev_del as
>>>>> media change/eject.
>>>>>
>>>>>
>>>> If blockdev_del only ejects media, then we need another command to get
>>>> rid of a blockdev.
>>>>
>>>>
>>> No. If you have a blockdev just to satisfy the guest device's need
>>> for a blockdev pointer, you can delete it automatically when the last
>>> reference goes.
>>>
>> That's not how netdev and chardev behave.
>>
>
> Ok. To me duplicate argument lists suggest a lack of orthogonality, though.
>
> How about
>
> blockdev_add id=...
> media_attach blockdev=..., media-parameters
> media_detach blockdev=...
> blockdev_del id=...
>
> So blockdev_add/del define/remove a slot for the media,
> media_attach/detach connect it to media.
Yes, those are orthogonal operations. Two more are side effects of
device_add and device_del: attach device model, detach device model.
My proposal provides two inessential operations purely for convenience:
define slot + connect media, and disconnect media + remove slot. These
patterns are very common.
>>>> Unless you propose that blockdev_del merely ejects media if the blockdev
>>>> is being used by a device, but destroys the blockdev outright if not.
>>>> But that would be sick, wouldn't it?
>>>>
>>>>
>>> Create a blockdev implicitly with guest device creation, and use
>>> blockdev_add (or media_attach) to attach the media.
>>>
>>> (but that creates a window where the guest device is visible but media
>>> is not yet inserted?)
>>>
>> Think so, for hot plug.
>>
>> Actually, the device model driver would reject an empty blockdev, unless
>> it's a device with removable media, such as a CD-ROM.
>>
>> Having a device with fixed media go through a "no media yet" state
>> during initialization just complicates things. Defining the media
>> *before* creating the device is much simpler.
>>
>
> That is true. Maybe we should just ignore the duplication.
It's fine to create empty blockdev, insert media, attach device model,
even if the device model wants fixed media.
Nevertheless, I think my convenience shortcuts make sense.
- [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/10
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/16
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs,
Markus Armbruster <=
- Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/16
[Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Avi Kivity, 2010/06/15
- [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Gerd Hoffmann, 2010/06/15
- [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Kevin Wolf, 2010/06/16
- [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/16
- Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Anthony Liguori, 2010/06/16
- Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Kevin Wolf, 2010/06/16
- Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Christoph Hellwig, 2010/06/16
- Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Markus Armbruster, 2010/06/16
- Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs, Anthony Liguori, 2010/06/16