[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_ME
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED |
Date: |
Thu, 9 Feb 2012 14:07:00 -0200 |
On Thu, 09 Feb 2012 16:01:21 +0100
Markus Armbruster <address@hidden> wrote:
> Luiz Capitulino <address@hidden> writes:
>
> > I've tried to implement a BLOCK_MEDIUM_EJECT event that, as we discussed[1],
> > would be emitted by guest-initiated ejects and by the QMP/HMP eject and
> > change
> > commands.
> >
> > However, that turned to be a bit problematic, because the eject and change
> > commands don't exactly handle tray movements: they actually insert/purge a
> > medium from from the drive.
>
> The monitor commands are complex, because they do several things, and
> the exact things they do depends on circumstances. In my experience,
> it's best to think in basic operations until you understand the problem,
> then bring in the complex commands. If you bring them in any earlier,
> you'll get lost in detail and confused.
>
> > Consider this example: you have a medium inserted and locked; a first eject
> > from HMP will tell the guest to eject the medium; if the guest does eject, a
> > second eject from HMP will just purge the medium (in which case
> > BLOCK_MEDIUM_EJECT is a bad event to be emitted).
> >
> > What we really want to do is to tell mngt that the medium was purged.
> >
> > The same is valid for the change command: we want to inform mngt if a medium
> > was inserted or purged and not emulate tray movements with two eject events
> > as we discussed[1].
> >
> > So, the solution I came up with is to have two events:
> >
> > o GUEST_MEDIUM_EJECTED: emitted when the tray state is changed by the guest
> > o BLOCK_MEDIUM_CHANGED: emitted when there's a medium change. This should
> > happen when the eject and change QMP/HMP commands are used
>
> I think what I got in mind is close to your proposal, but the thinking
> that gets me there is different. Let me explain it.
>
> The tray can be modelled as a simple state machine. Our problem "notify
> management app of tray-related events" then becomes "notify on state
> transition".
>
> Tray state is just three bits: open/closed, locked/unlocked,
> medium/empty. A state transition changes one bit, i.e. we have three
> pairs of them. There are a few constraints, all obvious: closed -> open
> requires unlocked, and empty <-> medium require open.
>
> The three pairs of state transitions correspond to three pairs of QMP
> events, each with a boolean argument[*]: one for open <-> closed, one for
> locked <-> unlocked, and one for medium <-> empty.
>
> These events report tray state transitions fully by construction.
> That's a feature.
>
> The medium/empty bit belongs to the block layer. So the block layer
> should emit the corresponding event.
>
> The open/closed bit and the locked/unlocked bit belong to the device
> model. So the device model should emit the event when it changes the
> bit. When device models need to call into the block layer whenever they
> change such a bit, then its fine (even desirable) to put the even
> emission into the block layer.
>
> Note there is no mention whatsoever of what caused the state transition.
> That's a feature.
>
>
> Now let's compare your proposal to my ideas. Your BLOCK_MEDIUM_CHANGED
> appears to track my medium <-> empty. You emit it from the block
> layer's bdrv_dev_change_media_cb(). Called to notify device models
> whenever the block layer changes media. The "whenever it changes media"
> part makes it a convenient choke point.
>
> 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.
The purpose of the note is not to clarify, but to emphasize that the event
is about guest initiated ejects. Also, I disagree it's more complex, actually
I think it's quite simple vs. emitting the eject event from the eject and
change commands, as this can be messy because of their complicated semantics.
> This is just my analysis of the problem. If folks think your proposal
> serves their needs, and Kevin is happy with it, I won't object.
No feedback so far.
- [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Luiz Capitulino, 2012/02/07
- [Qemu-devel] [PATCH 2/5] block: bdrv_eject(): Make eject_flag a real bool, Luiz Capitulino, 2012/02/07
- [Qemu-devel] [PATCH 3/5] block: bdrv_eject(): Add tray_changed parameter, Luiz Capitulino, 2012/02/07
- [Qemu-devel] [PATCH 5/5] qmp: add the BLOCK_MEDIUM_CHANGED event, Luiz Capitulino, 2012/02/07
- [Qemu-devel] [PATCH 4/5] qmp: add the GUEST_MEDIUM_EJECTED event, Luiz Capitulino, 2012/02/07
- [Qemu-devel] [PATCH 1/5] block: Rename bdrv_mon_event() & BlockMonEventAction, Luiz Capitulino, 2012/02/07
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Markus Armbruster, 2012/02/09
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED,
Luiz Capitulino <=
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Paolo Bonzini, 2012/02/10
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Markus Armbruster, 2012/02/10
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Luiz Capitulino, 2012/02/10
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Kevin Wolf, 2012/02/10
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Paolo Bonzini, 2012/02/10
- Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED, Paolo Bonzini, 2012/02/10