qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v22 25/30] qmp: add x-debug-block-d


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v22 25/30] qmp: add x-debug-block-dirty-bitmap-sha256
Date: Fri, 7 Jul 2017 07:30:39 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 07/07/2017 03:13 AM, Daniel P. Berrange wrote:
> On Fri, Jul 07, 2017 at 10:05:22AM +0200, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy <address@hidden> writes:
>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>>> ---
>>>  block/dirty-bitmap.c         |  5 +++++
>>>  blockdev.c                   | 25 +++++++++++++++++++++++++
>>>  include/block/dirty-bitmap.h |  1 +
>>>  include/qemu/hbitmap.h       |  8 ++++++++
>>>  qapi/block-core.json         | 27 +++++++++++++++++++++++++++
>>>  tests/Makefile.include       |  2 +-
>>>  util/hbitmap.c               | 11 +++++++++++
>>>  7 files changed, 78 insertions(+), 1 deletion(-)
>> [...]
>>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>>> index 5c42cc7790..6ad8585400 100644
>>> --- a/qapi/block-core.json
>>> +++ b/qapi/block-core.json
>>> @@ -1644,6 +1644,33 @@
>>>    'data': 'BlockDirtyBitmap' }
>>>  
>>>  ##
>>> +# @BlockDirtyBitmapSha256:
>>> +#
>>> +# SHA256 hash of dirty bitmap data
>>> +#
>>> +# @sha256: ASCII representation of SHA256 bitmap hash
>>
>> Spell it SHA-256, please.  The member name @sha256 can stay.
>>
>> SHA-256 is 256 binary bits.  Please specify how they are represented in
>> ASCII.  It better be base64 (RFC 4648), because we use that elsewhere.
> 
> It is filled later in this patch using qcrypto_hash_digest, so it is just
> a hex string representing the hash, not base64. For the latter you can
> use qcrypto_hash_base64

hex (aka base16) is used for displaying UUIDs across QMP.  Furthermore,
this is an x- command, useful only for debugging, so we can feel free to
change the underlying implementation without breaking clients (if we
prefer to go with the shorter base64 string instead of the longer hex
string, even if we make that switch after a release).  Still, it's nice
to avoid churn, and Markus does have a point about reusing a common
base64 theme for displaying arbitrary binary data, rather than having ad
hoc differences.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]