Re: [Qemu-devel] [PATCH] block/dirty-bitmap: Documentation and Comment fixups

[John Snow <jsnow@redhat.com>]

On 1/31/19 3:29 AM, Vladimir Sementsov-Ogievskiy wrote:
> 
> About @frozen and @locked, we can also note that they can't be exported through NBD.
> We can summarize, that @frozen and @locked means that user can't use them in any
> command, and the only option is to list them. However even info->count information
> should not be considered as something meaningful, as bitmaps are under some operations.
> And we can also use same paragraph for @frozen and @locked, as a first step to @frozen
> deprecation.

There's a subtle difference in the two, namely that:

(1) Frozen may or may not record new writes, but they don't "show up"
until after the operation is over, because it's using a second bitmap as
a temporary buffer.

(2) Locked may or may not record new writes *immediately*.

Regardless, I'm realizing that for both Frozen and Locked bitmaps we
want to allow users to know if the bitmap is recording or not. (And
possibly if there is a temporary write cache or not, but maybe it's not
important.)

Maybe we want two new fields on query:

Recording/Enabled: [True | False]
Busy/Locked:       [True | False] (or "Locked)

which will then deprecate the status field. This doesn't manage to
communicate the write cache nuance, but maybe we don't need to.

(It also doesn't help elucidate whether or not the successor is
active/disabled, but even for migration once the guest has started, the
successors are always enabled, right?)

Thoughts?