Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> On 02/09/2012 04:01 PM, Markus Armbruster wrote:
>> Your GUEST_MEDIUM_EJECTED does*not*  track my open<->  closed.  I think
>> it's more complex than a straight open<->  closed event.  Evidence: your
>> event documentation in qmp-events.txt needs an extra note to clarify
>> when exactly the event is emitted.
>
> I think I agree at this point that always generating an event for open
> <-> closed would make sense.
>
> However, we need to write a proper state machine rather than keeping
> it implicit.  Events would be generated in the state machine rather
> than magically in bdrv_eject/bdrv_close.  We could also take the
> occasion to move all this out of block.c which is becoming huge.  So
> we would have:
>
> guest eject, tray locked:
>     nothing
>
> guest eject, tray unlocked:
>     BLOCK_MEDIUM_EJECT
>     empty/full not affected
>
> guest eject, tray open:
>     BLOCK_MEDIUM_EJECT
>     empty/full not affected
>
> eject, tray locked:
>     eject request sent to guest
>     guest responds to eject request as above
>
> eject, tray unlocked and full:
>     BLOCK_MEDIUM_EJECT
>     BLOCK_MEDIUM_CHANGED
>
> eject, tray unlocked and empty:
>     BLOCK_MEDIUM_EJECT
>
> eject, tray open and full:
>     BLOCK_MEDIUM_CHANGED
>
> eject, tray open and empty:
>     no event
>
> change, tray locked:
>     eject request sent to guest
>     guest responds to eject request as above
>
> change, tray unlocked and full:
>     BLOCK_MEDIUM_EJECT (to open)
>     BLOCK_MEDIUM_CHANGED (perhaps twice? full -> empty -> full)
>     BLOCK_MEDIUM_EJECT (to close)
>
> change, tray unlocked and empty:
>     BLOCK_MEDIUM_EJECT (to open)
>     BLOCK_MEDIUM_CHANGED
>     BLOCK_MEDIUM_EJECT (to close)
>
> change, tray open and full:
>     BLOCK_MEDIUM_CHANGED (perhaps twice?)
>     BLOCK_MEDIUM_EJECT (to close)
>
> change, tray open and empty:
>     BLOCK_MEDIUM_CHANGED
>     BLOCK_MEDIUM_EJECT (to close)
>
> Luiz, can you try making a proof of concept of this state machine?
> Events then would hopefully come natural.

Making the tray state machine explicit may make sense.  But we also need
to preserve the sane guest / host split: tray movement and locking is
guest matter, handling media in an open tray is host matter.

Moreover, let's not think "eject" and "change".  These are complex
actions that should be built from basic parts.  The verbs I want used
are open, close, lock, unlock, insert, remove.

Eject becomes something like open (if not already open) + remove (if
open and not empty).

Change becomes something like open (if not already open) + remove (if
open and not empty) + insert (if empty) + close (if open).