On 2/11/19 7:02 PM, 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. > ---
No S-o-b?
> +++ b/qapi/block-core.json
> @@ -455,7 +455,13 @@
> #
> # @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 4.0)
I'd leave this one as (since 2.4). The deprecation clock is starting in
4.0, but the field has been present longer, and it is still obvious to
readers...
> +#
> +# @recording: true if the bitmap is recording new writes from the guest.
> +# Replaces `active` status. (since 4.0)
...that the replacement fields are only usable in 4.0 and newer.
> +#
> +# @busy: true if the bitmap is in-use by some operation (NBD or jobs)
> +# and cannot be modified via QMP right now. (since 4.0)
> #
> # @persistent: true if the bitmap will eventually be flushed to persistent
> # storage (since 4.0)
> @@ -464,6 +470,7 @@
> ##
> { 'struct': 'BlockDirtyInfo',
> 'data': {'*name': 'str', 'count': 'int', 'granularity': 'uint32',
> + 'recording': 'bool', 'busy': 'bool',
> 'status': 'DirtyBitmapStatus', 'persistent': 'bool' } }
The UI changes look reasonable.
No iotests coverage of "busy":true?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
