Re: [Qemu-devel] [PATCH 4/4] qmp: add BLOCK_MEDIUM_EJECT event

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 17.02.2012 12:48, schrieb Markus Armbruster:
>> Kevin Wolf <address@hidden> writes:
>> 
>>> Am 17.02.2012 11:32, schrieb Paolo Bonzini:
>>>> On 02/16/2012 03:10 PM, Luiz Capitulino wrote:
>>>>> We have two external entities: the guest and the mngt app. It seems to me 
>>>>> that
>>>>> the guest is seeing each step at a time.
>>>>
>>>> The guest is seeing each step separately, but that is managed by the
>>>> device model (which sends two separate error codes: a NOT READY for
>>>> opening the tray, and a UNIT ATTENTION for closing the tray and changing
>>>> medium) rather than by the monitor.
>>>
>>> But this separation isn't set in stone. Maybe it would make sense to
>>> move the logic into the block layer. Of course, then it would have to
>>> meet the needs of floppies as well.
>> 
>> And whatever other device with removable media comes up.
>> 
>> We should not move device-specific stuff from device models into the
>> block layer.  The block layer is fat enough as it is.  And it's not
>> meant for sharing code among device models.  There are better ways to do
>> that.
>
> My motivation is not sharing code but getting the model right.
>
> As Paolo says, currently we only tell the device that the medium has
> changed. It is the device's responsibility to fake separate tray
> open/close events.
>
> So my question is just if the monitor/block layer shouldn't really be
> responsible for opening the tray before they change the medium and close
> the tray again. This doesn't look device-specific to me at all.

Looks like I misunderstood you :)

I think BlockDevOps method(s) to move the tray are okay.  If you want
more generality there, call it "prepare for media change" (called right
before media goes out) and "media changed" (called right after media
went in).

> But even though I think that it would be conceptionally cleaner to do it
> this way, it would probably be a bad idea as faking the states requires
> knowledge of when the guest has read out the intermediate status. and
> only devices have this knowledge.

I'm not sure I got the last paragraph.