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

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(a)redhat.com&gt; > ---

> +++ 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?