From: Paolo Bonzini <pbonzini@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: kwolf@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED
Date: Fri, 10 Feb 2012 08:58:17 +0100 [thread overview]
Message-ID: <4F34CE19.7010806@redhat.com> (raw)
In-Reply-To: <m339akuk3i.fsf@blackfin.pond.sub.org>
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
next prev parent reply other threads:[~2012-02-10 8:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 18:09 [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED Luiz Capitulino
2012-02-07 18:09 ` [Qemu-devel] [PATCH 1/5] block: Rename bdrv_mon_event() & BlockMonEventAction Luiz Capitulino
2012-02-07 18:09 ` [Qemu-devel] [PATCH 2/5] block: bdrv_eject(): Make eject_flag a real bool Luiz Capitulino
2012-02-07 18:09 ` [Qemu-devel] [PATCH 3/5] block: bdrv_eject(): Add tray_changed parameter Luiz Capitulino
2012-02-07 18:09 ` [Qemu-devel] [PATCH 4/5] qmp: add the GUEST_MEDIUM_EJECTED event Luiz Capitulino
2012-02-07 18:09 ` [Qemu-devel] [PATCH 5/5] qmp: add the BLOCK_MEDIUM_CHANGED event Luiz Capitulino
2012-02-09 15:01 ` [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED Markus Armbruster
2012-02-09 16:07 ` Luiz Capitulino
2012-02-10 9:27 ` Markus Armbruster
2012-02-10 17:20 ` Luiz Capitulino
2012-02-10 7:58 ` Paolo Bonzini [this message]
2012-02-10 9:36 ` Markus Armbruster
2012-02-10 17:04 ` Luiz Capitulino
2012-02-10 17:55 ` Kevin Wolf
2012-02-10 19:39 ` Paolo Bonzini
2012-02-10 20:47 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F34CE19.7010806@redhat.com \
--to=pbonzini@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.