On 2/18/19 12:27 PM, Vladimir Sementsov-Ogievskiy wrote:
> 14.02.2019 2:23, John Snow wrote:
>> These mean the same thing now. Unify them and rename the merged call
>> bdrv_dirty_bitmap_busy to indicate semantically what we are describing,
>> as well as help disambiguate from the various _locked and _unlocked
>> versions of bitmap helpers that refer to mutex locks.
>>
>> Signed-off-by: John Snow <js...@redhat.com>
>> Reviewed-by: Eric Blake <ebl...@redhat.com>
>> ---
>> block/dirty-bitmap.c | 41 +++++++++++++++-------------------
>> blockdev.c | 18 +++++++--------
>> include/block/dirty-bitmap.h | 5 ++---
>> migration/block-dirty-bitmap.c | 6 ++---
>> nbd/server.c | 6 ++---
>> 5 files changed, 35 insertions(+), 41 deletions(-)
>>
>> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
>> index 2042c62602..8ab048385a 100644
>> --- a/block/dirty-bitmap.c
>> +++ b/block/dirty-bitmap.c
>> @@ -48,9 +48,9 @@ struct BdrvDirtyBitmap {
>> QemuMutex *mutex;
>> HBitmap *bitmap; /* Dirty bitmap implementation */
>> HBitmap *meta; /* Meta dirty bitmap */
>> - bool qmp_locked; /* Bitmap is locked, it can't be modified
>> - through QMP */
>> - BdrvDirtyBitmap *successor; /* Anonymous child; implies user_locked
>> state */
>> + bool busy; /* Bitmap is busy, it can't be modified
>> through
>> + QMP */
>
> better not "modified" but "used".. for example, export through NBD is not a
> modification.
>
True.
>> + BdrvDirtyBitmap *successor; /* Anonymous child, if any. */
>
> hm this comment change about successor relates more to previous patch, but I
> don't really care.
>
Oh, true.
>> char *name; /* Optional non-empty unique ID */
>> int64_t size; /* Size of the bitmap, in bytes */
>> bool disabled; /* Bitmap is disabled. It ignores all
>> writes to
>> @@ -188,22 +188,17 @@ bool bdrv_dirty_bitmap_has_successor(BdrvDirtyBitmap
>> *bitmap)
>> return bitmap->successor;
>> }
>>
>
>
> In comment for bdrv_dirty_bitmap_create_successor, there is "locked" word,
> which you forget to fix to "busy"
> with at least this fixed:
Good spot. Too many occurrences of the word "lock" to have looked for
them all.
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
>
>
