On Fri, 10 Feb 2012 10:36:06 +0100
Markus Armbruster <arm...@redhat.com> wrote:
> Paolo Bonzini <pbonz...@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?
