From: Eric Blake <eblake@redhat.com>
To: Alberto Garcia <berto@igalia.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2 11/12] block: Add an 'x-blockdev-reopen' QMP command
Date: Fri, 30 Nov 2018 14:50:56 -0600 [thread overview]
Message-ID: <ac477bbd-a984-42f4-13cc-e1e555cde952@redhat.com> (raw)
In-Reply-To: <19f8c53d020fa7b71b5e129791bb556b4678f468.1543590618.git.berto@igalia.com>
On 11/30/18 9:17 AM, Alberto Garcia wrote:
> This command allows reopening an arbitrary BlockDriverState with a
> new set of options. Some options (e.g node-name) cannot be changed
> and some block drivers don't allow reopening, but otherwise this
> command is modelled after 'blockdev-add' and the state of the reopened
> BlockDriverState should generally be the same as if it had just been
> added by 'blockdev-add' with the same set of options.
>
> One notable exception is the 'backing' option: 'x-blockdev-reopen'
> requires that it is always present unless the BlockDriverState in
> question doesn't have a current or default backing file.
>
> This command allows reconfiguring the graph by using the appropriate
> options to change the children of a node. At the moment it's possible
> to change a backing file by setting the 'backing' option to the name
> of the new node, but it should also be possible to add a similar
> functionality to other block drivers (e.g. Quorum, blkverify).
>
> Although the API is unlikely to change, this command is marked
> experimental for the time being so there's room to see if the
> semantics need changes.
>
> +++ b/qapi/block-core.json
> @@ -3808,6 +3808,48 @@
> { 'command': 'blockdev-add', 'data': 'BlockdevOptions', 'boxed': true }
>
> ##
> +# @x-blockdev-reopen:
> +#
> +# Reopens a block device using the given set of options. Any option
> +# not specified will be reset to its default value regardless of its
> +# previous status. If an option cannot be changed or a particular
> +# driver does not support reopening then the command will return an
> +# error.
Possible alternative implementation (although it would be a major
rewrite of this series) - if EVERY option has a counterpart OptionOrNull
alternate type, you could use omitting the option to mean 'leave the
option's current value unchanged', "option":null to mean 'reset the
option to its default state', and "option":"value" to change the option
to value.
So, what happens when a newer qemu version adds a new option field?
Presumably, the added field is optional (if it were mandatory, it would
break old clients), and an older client is likely to omit the field.
With your approach, the client omitting the field on reopen is thus
requesting that the field be reset back to its default state - but since
the client already omitted the option during open, the field is already
in its default state, so there is no change.
With my approach, the client omitting the field is thus requesting that
the field be left alone - but since the client already omitted the
option during open, the field is already in its default state.
So either approach should work, and yours seems simpler (at least, less
invasive to adding new QAPI FooOrNull alternates).
> +#
> +# The top-level @node-name option (from BlockdevOptions) must be
> +# specified and is used to select the block device to be reopened.
> +# Other @node-name options must be either omitted or set to the
> +# current name of the appropriate node. This command won't change any
> +# node name and any attempt to do it will result in an error.
> +#
> +# In the case of options that refer to child nodes, the behavior of
> +# this command depends on the value:
> +#
> +# 1) A set of options (BlockdevOptions): the child is reopened with
> +# the specified set of options.
> +#
> +# 2) A reference to the current child: the child is reopened using
> +# its existing set of options.
> +#
> +# 3) A reference to a different node: the current child is replaced
> +# with the specified one.
> +#
> +# 4) NULL: the current child (if any) is detached.
> +#
> +# Options (1) and (2) are supported in all cases, but at the moment
> +# only @backing allows replacing or detaching an existing child.
> +#
> +# Unlike with blockdev-add, the @backing option must always be present
> +# unless the node being reopened does not have a backing file and its
> +# image does not have a default backing file name as part of its
> +# metadata.
> +#
> +# Since: 3.2
> +##
> +{ 'command': 'x-blockdev-reopen',
> + 'data': 'BlockdevOptions', 'boxed': true }
Looks reasonable to me. Also a wise decision to keep the x- prefix
while we play with it, in case we change something.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2018-11-30 20:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-30 15:17 [Qemu-devel] [RFC PATCH v2 00/12] Add a 'x-blockdev-reopen' QMP command Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 01/12] block: Allow freezing BdrvChild links Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 02/12] block: Freeze the backing chain for the duration of the commit job Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 03/12] block: Freeze the backing chain for the duration of the mirror job Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 04/12] block: Freeze the backing chain for the duration of the stream job Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 05/12] block: Add 'keep_old_opts' parameter to bdrv_reopen_queue() Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 06/12] block: Handle child references in bdrv_reopen_queue() Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 07/12] block: Allow omitting the 'backing' option in certain cases Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 08/12] block: Allow changing the backing file on reopen Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 09/12] block: Add 'runtime_opts' and 'mutable_opts' fields to BlockDriver Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 10/12] block: Add bdrv_reset_options_allowed() Alberto Garcia
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 11/12] block: Add an 'x-blockdev-reopen' QMP command Alberto Garcia
2018-11-30 20:50 ` Eric Blake [this message]
2018-11-30 15:17 ` [Qemu-devel] [RFC PATCH v2 12/12] qemu-iotests: Test the x-blockdev-reopen " Alberto Garcia
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=ac477bbd-a984-42f4-13cc-e1e555cde952@redhat.com \
--to=eblake@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).