Re: [Qemu-devel] [PATCH v3] qapi: add dirty-bitmaps to query-named-block-nodes result

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2320 bytes --]

On 7/17/19 12:39 PM, John Snow wrote:
> 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(-)

> +++ 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)
> +#

Naming-wise, everything else in this struct uses 'foo_bar' while your
addition uses 'foo-bar'.  But at this point, I don't know if it's worth
uglifying this addition just to fit in.

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

s/BlockDirtyInfo/BlockDeviceInfo/

With the spelling fix,

Reviewed-by: Eric Blake <eblake@redhat.com>

Is this worth squeezing into 4.1, to start the deprecation clock one
cycle earlier (on the grounds that the missing information for anonymous
nodes is a bug)?  Or am I pushing the boundaries too far, where keeping
this as 4.2 material remains the best course of action?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]