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