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
signature.asc
Description: OpenPGP digital signature