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