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