All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: qemu-devel <qemu-devel@nongnu.org>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event
Date: Fri, 27 Jan 2012 13:10:39 +0100	[thread overview]
Message-ID: <4F22943F.5080704@redhat.com> (raw)
In-Reply-To: <20120124161628.4bf2592c@doriath.home>

On 01/24/2012 07:16 PM, Luiz Capitulino wrote:
> @@ -237,6 +238,17 @@ static bool do_check_io_limits(BlockIOLimit *io_limits)
>      return true;
>  }
>
> +static void on_medium_eject(BlockDriverState *bs, int is_ejected)
> +{
> +    QObject *data;
> +
> +    data = qobject_from_jsonf("{ 'device': %s, 'ejected': %i }",
> +                              bdrv_get_device_name(bs), is_ejected);
> +    monitor_protocol_event(QEVENT_BLOCK_MEDIUM_EJECT, data);
> +
> +    qobject_decref(data);
> +}
> +
>  DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>  {
>      const char *buf;
> @@ -503,6 +515,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
>      QTAILQ_INSERT_TAIL(&drives, dinfo, next);
>
>      bdrv_set_on_error(dinfo->bdrv, on_read_error, on_write_error);
> +    bdrv_dev_set_medium_eject_notify(dinfo->bdrv, on_medium_eject);
>
>      /* disk I/O throttling */
>      bdrv_set_io_limits(dinfo->bdrv, &io_limits);

block.c/blockdev.c separation is nice, but do we really need a function 
pointer?  Also, we're already emitting the BLOCK_IO_ERROR event in 
block.c; is that another place to cleanup, or is this overkill and we 
can just put bdrv_dev_medium_eject_notify in block.c?

> diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
> index 0adb27b..4b4bc61 100644
> --- a/hw/ide/atapi.c
> +++ b/hw/ide/atapi.c
> @@ -885,6 +885,7 @@ static void cmd_start_stop_unit(IDEState*s, uint8_t*  buf)
>           }
>           bdrv_eject(s->bs, !start);
>           s->tray_open = !start;
> +        bdrv_dev_medium_eject_notify(s->bs, !start);
>       }
>
>       ide_atapi_cmd_ok(s);
> diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
> index 5d8bf53..35e55f4 100644
> --- a/hw/scsi-disk.c
> +++ b/hw/scsi-disk.c
> @@ -1061,6 +1061,7 @@ static int scsi_disk_emulate_start_stop(SCSIDiskReq *r)
>           }
>           bdrv_eject(s->qdev.conf.bs, !start);
>           s->tray_open = !start;
> +        bdrv_dev_medium_eject_notify(s->qdev.conf.bs, !start);
>       }
>       return 0;
>   }

Can you do the call directly in bdrv_eject (but I would skip 
bdrv_close)?  The only other place where bdrv_eject is called is from 
block/raw.c's raw_eject, but I think you should only emit the event if 
bs->device_name[0] (otherwise the event is quite useless) and bs->file 
will fail the test.

Paolo

  parent reply	other threads:[~2012-01-27 12:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24 18:16 [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event Luiz Capitulino
2012-01-24 20:03 ` Eric Blake
2012-01-25  8:41   ` Kevin Wolf
2012-01-25 12:42     ` Luiz Capitulino
2012-01-25 13:23       ` Kevin Wolf
2012-01-25 13:32         ` Paolo Bonzini
2012-01-25 13:43           ` Kevin Wolf
2012-01-25 13:49           ` Markus Armbruster
2012-01-25 13:42         ` Luiz Capitulino
2012-01-26 17:57       ` Luiz Capitulino
2012-01-27  9:52         ` Kevin Wolf
2012-01-27 12:02           ` Paolo Bonzini
2012-01-30 15:18           ` Luiz Capitulino
2012-01-30 15:43             ` Kevin Wolf
2012-01-30 15:55               ` Paolo Bonzini
2012-01-31  8:33                 ` Kevin Wolf
2012-01-31  9:23               ` Markus Armbruster
2012-01-31 13:46                 ` Luiz Capitulino
2012-01-25 10:19 ` Markus Armbruster
2012-01-25 13:31   ` Luiz Capitulino
2012-01-25 14:12     ` Markus Armbruster
2012-01-27 12:10 ` Paolo Bonzini [this message]
2012-01-30 15:36   ` Luiz Capitulino

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=4F22943F.5080704@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.