Re: [Qemu-devel] [PATCH v7 28/39] blockdev: Add blockdev-open-tray

[Kevin Wolf]

Am 19.10.2015 um 17:53 hat Max Reitz geschrieben:
> Signed-off-by: Max Reitz <address@hidden>
> ---
>  blockdev.c           | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>  qapi/block-core.json | 23 +++++++++++++++++++++++
>  qmp-commands.hx      | 39 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 111 insertions(+)

> +
> +    if (blk_dev_is_medium_locked(blk)) {
> +        blk_dev_eject_request(blk, force);
> +    } else {
> +        blk_dev_change_media_cb(blk, false);
> +    }

This seems to be inconsistent with the command documentation: In the
case of a forced eject request, the tray is just unlocked, but not
opened.

> +##
> +# @blockdev-open-tray:
> +#
> +# Opens a block device's tray. If there is a block driver state tree 
> inserted as
> +# a medium, it will become inaccessible to the guest (but it will remain
> +# associated to the block device, so closing the tray will make it accessible
> +# again).
> +#
> +# If the tray was already open before, this will be a no-op.
> +#
> +# @device: block device name
> +#
> +# @force:  #optional if false (the default), an eject request will be sent to
> +#          the guest if it has locked the tray (and the tray will not be 
> opened
> +#          immediately); if true, the tray will be opened regardless of 
> whether
> +#          it is locked
> +#
> +# Since: 2.5
> +##
> +{ 'command': 'blockdev-open-tray',
> +  'data': { 'device': 'str',
> +            '*force': 'bool' } }

This API makes it impossible for the management application to know
whether the tray has actually been opened or just an eject request has
been made.

Is the expected use that management sets a timeout and waits for a
tray opened event? If so, worth documenting?

Kevin