All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-block@nongnu.org, libvir-list@redhat.com,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result
Date: Wed, 24 Jul 2019 06:47:44 +0200	[thread overview]
Message-ID: <87imrsqbrj.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20190717173937.18747-1-jsnow@redhat.com> (John Snow's message of "Wed, 17 Jul 2019 13:39:37 -0400")

John Snow <jsnow@redhat.com> writes:

> From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>
> Let's add a possibility to query dirty-bitmaps not only on root nodes.
> It is useful when dealing both with snapshots and incremental backups.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> [Added deprecation information. --js]
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
>  block/qapi.c         |  5 +++++
>  qapi/block-core.json |  6 +++++-
>  qemu-deprecated.texi | 12 ++++++++++++
>  3 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/block/qapi.c b/block/qapi.c
> index 917435f022..15f1030264 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -79,6 +79,11 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
>          info->backing_file = g_strdup(bs->backing_file);
>      }
>  
> +    if (!QLIST_EMPTY(&bs->dirty_bitmaps)) {
> +        info->has_dirty_bitmaps = true;
> +        info->dirty_bitmaps = bdrv_query_dirty_bitmaps(bs);
> +    }
> +
>      info->detect_zeroes = bs->detect_zeroes;
>  
>      if (blk && blk_get_public(blk)->throttle_group_member.throttle_state) {
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 0d43d4f37c..9210ae233d 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -360,6 +360,9 @@
>  # @write_threshold: configured write threshold for the device.
>  #                   0 if disabled. (Since 2.3)
>  #
> +# @dirty-bitmaps: dirty bitmaps information (only present if node
> +#                 has one or more dirty bitmaps) (Since 4.2)
> +#
>  # Since: 0.14.0
>  #
>  ##
> @@ -378,7 +381,7 @@
>              '*bps_wr_max_length': 'int', '*iops_max_length': 'int',
>              '*iops_rd_max_length': 'int', '*iops_wr_max_length': 'int',
>              '*iops_size': 'int', '*group': 'str', 'cache': 'BlockdevCacheInfo',
> -            'write_threshold': 'int' } }
> +            'write_threshold': 'int', '*dirty-bitmaps': ['BlockDirtyInfo'] } }
>  
>  ##
>  # @BlockDeviceIoStatus:
> @@ -656,6 +659,7 @@
>  #
>  # @dirty-bitmaps: dirty bitmaps information (only present if the
>  #                 driver has one or more dirty bitmaps) (Since 2.0)
> +#                 Deprecated in 4.2; see BlockDirtyInfo instead.
>  #
>  # @io-status: @BlockDeviceIoStatus. Only present if the device
>  #             supports it and the VM is configured to stop on errors
> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
> index c90b08d553..6374b66546 100644
> --- a/qemu-deprecated.texi
> +++ b/qemu-deprecated.texi
> @@ -134,6 +134,18 @@ The ``status'' field of the ``BlockDirtyInfo'' structure, returned by
>  the query-block command is deprecated. Two new boolean fields,
>  ``recording'' and ``busy'' effectively replace it.
>  
> +@subsection query-block result field dirty-bitmaps (Since 4.2)
> +
> +The ``dirty-bitmaps`` field of the ``BlockInfo`` structure, returned by
> +the query-block command is itself now deprecated. The ``dirty-bitmaps``
> +field of the ``BlockDeviceInfo`` struct should be used instead, which is the
> +type of the ``inserted`` field in query-block replies, as well as the
> +type of array items in query-named-block-nodes.

Would the text be clearer if it talked only about commands, not about
types?

Here's my (laconic) try:

   @subsection query-block result field dirty-bitmaps (Since 4.2)

   In the result of query-block, member ``dirty-bitmaps'' has been moved
   into member ``inserted''.

Aside: same for existing @subsection query-block result field
dirty-bitmaps[i].status (since 4.0).

> +Since the ``dirty-bitmaps`` field is optionally present in both the old and
> +new locations, clients must use introspection to learn where to anticipate
> +the field if/when it does appear in command output.
> +

I find this hint a bit confusing.  Do we need it?

If yes, laconic me again:

   Clients should use introspection to learn whether ``dirty-bitmaps'' is
   in the new location.

>  @subsection query-cpus (since 2.12.0)
>  
>  The ``query-cpus'' command is replaced by the ``query-cpus-fast'' command.


  parent reply	other threads:[~2019-07-24  4:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 17:39 [Qemu-devel] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result John Snow
2019-07-17 17:47 ` John Snow
2019-07-17 19:13 ` Eric Blake
2019-07-17 19:21   ` John Snow
2019-07-17 20:05     ` Eric Blake
2019-07-17 20:32       ` John Snow
2019-07-17 21:12 ` John Snow
2019-07-18 10:20 ` [Qemu-devel] [libvirt] " no-reply
2019-07-18 17:32   ` John Snow
2019-07-24  4:47 ` Markus Armbruster [this message]
2019-07-24 22:06   ` [Qemu-devel] " John Snow
2019-07-25  6:06     ` Markus Armbruster
2019-07-25 16:13       ` John Snow

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=87imrsqbrj.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /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.