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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Fri, 10 Feb 2012 10:36:06 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Paolo Bonzini <pbonzini@redhat.com> 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

I think we should only emit the event when the tray actually moves, that's what
mngt is interested in.

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

I don't think BLOCK_MEDIUM_EJECT should be emitted if the tray is already open.

> > eject, tray unlocked and empty:
> >     BLOCK_MEDIUM_EJECT

And closed...

> > eject, tray open and full:
> >     BLOCK_MEDIUM_CHANGED
> >
> > eject, tray open and empty:
> >     no event

Yes.

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

This reminds me about an earlier try where I did the following, iirc:

 1. added commands blockdev-tray-open, blockdev-tray-close, blockdev-medium-insert,
    blockdev-medium-remove
 2. added the events: BLOCK_TRAY_OPEN, BLOCK_TRAY_CLOSE, BLOCK_MEDIUM_INSERTED
    BLOCK_MEDIUM_REMOVED, which would be emitted when the relating command is issued
    (maybe the events could just be BLOCK_TRAY_CHANGED & BLOCK_MEDIUM_CHANGED)
 3. re-wrote eject and change in terms of the new commands, note that you get the
    events for free

Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN & BLOCK_TRAY_CLOSE. Then
I think this is a complete solution.

Do you guys agree?