qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).