On 02/27/2015 10:24 AM, Vladimir Sementsov-Ogievskiy wrote:
> Reviewed-by: John Snow <js...@redhat.com>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@parallels.com>
> ---
>  block.c                | 1 +
>  include/qemu/hbitmap.h | 8 ++++++++
>  qapi/block-core.json   | 4 +++-
>  util/hbitmap.c         | 8 ++++++++
>  4 files changed, 20 insertions(+), 1 deletion(-)
> 

> +++ b/qapi/block-core.json
> @@ -336,11 +336,13 @@
>  #
>  # @frozen: whether the dirty bitmap is frozen (Since 2.3)
>  #
> +# @md5: md5 checksum of the last bitmap level (since 2.3)
> +#
>  # Since: 1.3
>  ##
>  { 'type': 'BlockDirtyInfo',
>    'data': {'*name': 'str', 'count': 'int', 'granularity': 'uint32',
> -           'disabled': 'bool', 'frozen': 'bool'} }
> +           'disabled': 'bool', 'frozen': 'bool', 'md5': 'str'} }

How long does it take to compute the md5 sum?  Is enabling this
information unconditionally going to significantly slow down the call,
when the information is useful primarily only for debugging?

That said, it looks okay code-wise, so as long as I am not uncovering a
design flaw:
Reviewed-by: Eric Blake <ebl...@redhat.com>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to