All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: amit.shah@redhat.com, aliguori@us.ibm.com, qemu-devel@nongnu.org,
	armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
Date: Mon, 30 May 2011 11:21:23 -0300	[thread overview]
Message-ID: <20110530112123.39ca4dc6@doriath> (raw)
In-Reply-To: <4DE3594F.20406@redhat.com>

On Mon, 30 May 2011 10:46:07 +0200
Kevin Wolf <kwolf@redhat.com> wrote:

> Am 27.05.2011 21:31, schrieb Luiz Capitulino:
> > Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
> > ---
> >  QMP/qmp-events.txt |   18 ++++++++++++++++++
> >  1 files changed, 18 insertions(+), 0 deletions(-)
> > 
> > diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> > index 0ce5d4e..d53c129 100644
> > --- a/QMP/qmp-events.txt
> > +++ b/QMP/qmp-events.txt
> > @@ -1,6 +1,24 @@
> >                     QEMU Monitor Protocol Events
> >                     ============================
> >  
> > +BLOCK_MEDIA_EJECT
> > +-----------------
> > +
> > +Emitted when a removable disk media (such as a CDROM or floppy) is ejected.
> > +
> > +Data:
> > +
> > +- "device": device name (json-string)
> > +
> > +Example:
> > +
> > +{ "event": "BLOCK_MEDIA_EJECT",
> > +    "data": { "device": "ide1-cd0" },
> > +    "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
> > +
> > +NOTE: A disk media can be ejected by the guest or by monitor commands (such
> > +as "eject" and "change")
> 
> The monitor command 'eject' already caused a lot of confusion, please
> don't make the same mistake in this event name. Even though I know more
> or less what eject can mean in qemu, I'm not sure what "eject" means for
> you in the context of this event.

I'll change it to report the tray status instead, as suggested by Markus.

> The 'eject' monitor command means that the image is closed and the
> BlockDriverState doesn't point to any image file any more. And then
> there's bdrv_eject(), which is what the guest can do, and it's about the
> virtual tray status.
> 
> Having a single event for both doesn't make sense because they are
> fundamentally different. Something like BLOCKDEV_CLOSE would be the
> right name for the 'eject' monitor command and maybe something like
> BLOCKDEV_TRAY_STATUS for the other one.

Well, there are two problems here. First, we shouldn't report something
like BLOCKDEV_CLOSE because closing a BlockDriverState is something
internal to qemu that clients/users shouldn't know about. The second
problem is that, unfortunately, clients do use "eject" to eject a
removable media. Actually it's _the_ interface available for that, so
not emitting the event there will probably confuse clients as much as
not having the event at all.

Maybe, a better solution is to fix eject to really eject the media
instead of closing its BlockDriverState and drop the event from the change
command.

  reply	other threads:[~2011-05-30 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-27 19:31 [Qemu-devel] [PATCH 0/3]: QMP: Introduce the BLOCK_MEDIA_EJECT event Luiz Capitulino
2011-05-27 19:31 ` [Qemu-devel] [PATCH 1/3] block: Rename bdrv_mon_event() Luiz Capitulino
2011-05-27 19:31 ` [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation Luiz Capitulino
2011-05-30  8:46   ` Kevin Wolf
2011-05-30 14:21     ` Luiz Capitulino [this message]
2011-05-30 14:54       ` Markus Armbruster
2011-05-31  7:09         ` Amit Shah
2011-05-31  7:59       ` Kevin Wolf
2011-05-27 19:31 ` [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event Luiz Capitulino
2011-05-28  7:58   ` Markus Armbruster
2011-05-30 14:09     ` Luiz Capitulino
2011-05-30 14:49       ` Markus Armbruster
2011-05-31  8:12         ` Kevin Wolf
2011-05-31 13:35           ` Luiz Capitulino
2011-05-31 13:40             ` Anthony Liguori

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=20110530112123.39ca4dc6@doriath \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=amit.shah@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@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.