Eric Blake <ebl...@redhat.com> writes:
> On 08/07/2017 09:45 AM, Markus Armbruster wrote:
>> hbitmap_count() returns uint64_t.
>> Clean up test-hbitmap.c to check its value with g_assert_cmpuint()
>> instead of g_assert_cmpint().
>> bdrv_get_dirty_count() and bdrv_get_meta_dirty_count() return its
>> value converted to int64_t. Clean them up to return it unadulterated.
>> This moves the implicit conversion to some callers, so clean them up,
>> mirror_run() assigns the value of bdrv_get_meta_dirty_count() to a
>> local int64_t variable. Change it to uint64_t. Signedness still gets
>> mixed up in the computation of s->common.len, but messing with that is
>> more than I can handle right now.
>> get_remaining_dirty() tallies bdrv_get_dirty_count() values in
>> int64_t. Its caller block_save_pending() converts it back to
>> uint64_t. Change get_remaining_dirty() to uint64_t.
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> block/dirty-bitmap.c | 4 ++--
>> block/mirror.c | 4 ++--
>> block/trace-events | 8 ++++----
>> include/block/dirty-bitmap.h | 4 ++--
>> migration/block.c | 4 ++--
>> tests/test-hbitmap.c | 16 +++++++++-------
>> 6 files changed, 21 insertions(+), 19 deletions(-)
> I don't know how much this will conflict with my pending work for
> byte-based block status, but I suspect it may be easier for your RFC to
> go in after my cleanups (I think you'll still have things to fix).
I fully expect to rebase on your work.