Re: [Qemu-block] [Qemu-devel] [PATCH v3 1/8] dirty-bitmap: improve bdrv_dirty_bitmap_next_zero

[Eric Blake]

On 9/10/18 11:49 AM, Vladimir Sementsov-Ogievskiy wrote:

> > > -int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start);
> > > +int64_t hbitmap_next_zero(const HBitmap *hb, uint64_t start, int64_t 
> > > end);
> > The interface looks weird because we can define a 'start' that's beyond
> > the 'end'.
> >
> > I realize that you need a signed integer for 'end' to signify EOF...
> > should we do a 'bytes' parameter instead? (Did you already do that in an
> > earlier version and we changed it?)
> >
> > Well, it's not a big deal to me personally.
>
> interface with constant end parameter is more comfortable for loop: we 
> don't need to update 'bytes' parameter on each iteration

But there's still the question of WHO should be calculating end. Your 
interface argues for the caller:

hbitmap_next_zero(start, start + bytes)

int64_t hbitmap_next_zero(...)
{
    while (offset != end) ...
}

while we're asking about a consistent interface for the caller (if most 
callers already have a 'bytes' rather than an 'end' computed):

hbitmap_next_zero(start, bytes)

int64_t hbitmap_next_zero(...)
{
    int64_t end = start + bytes;
    while (offset != end) ...
}

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org