Re: [Qemu-devel] [PATCH v3 01/10] block/dirty-bitmap: add recording and busy properties

[Eric Blake <eblake@redhat.com>]

On 2/25/19 9:01 AM, Vladimir Sementsov-Ogievskiy wrote:
> 23.02.2019 3:06, John Snow wrote:
>> The current API allows us to report a single status, which we've defined as:
>>
>> Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
>> Locked: no successor, qmp_locked. may or may not be enabled.
>> Disabled: Not frozen or locked, disabled.
>> Active: Not frozen, locked, or disabled.
>>
>> The problem is that both "Frozen" and "Locked" mean nearly the same thing,
>> and that both of them do not intuit whether they are recording guest writes
>> or not.
>>
>> This patch deprecates that status field and introduces two orthogonal
>> properties instead to replace it.
>>
>> Signed-off-by: John Snow <jsnow@redhat.com>
>> ---

>> +++ b/qapi/block-core.json
>> @@ -458,7 +458,14 @@
>>   #
>>   # @granularity: granularity of the dirty bitmap in bytes (since 1.4)
>>   #
>> -# @status: current status of the dirty bitmap (since 2.4)
>> +# @status: Deprecated in favor of @recording and @locked. (since 2.4)
>> +#
>> +# @recording: true if the bitmap is recording new writes from the guest.
>> +#             Replaces `active` and `disabled` statuses. (since 4.0)
>> +#
>> +# @busy: true if the bitmap is in-use by some operation (NBD or jobs)
>> +#        and cannot be modified via QMP or used by another operation.
>> +#        Replaces `locked` and `frozen` statuses. (since 4.0)
> 
> 
> Don't we want instead an array of flags? Which will include also persistent and
> inconsistent?

No, I don't think an array of flags is worth the extra complications in
generation and parsing of the JSON.

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