RE: [PATCH v19 3/7] xbitmap: add more operations

On Saturday, December 16, 2017 3:22 AM, Matthew Wilcox wrote:

On Fri, Dec 15, 2017 at 10:49:15AM -0800, Matthew Wilcox wrote:

quoted

Here's the API I'm looking at right now.  The user need take no lock;
the locking (spinlock) is handled internally to the implementation.

Another place I saw your comment " The xb_ API requires you to handle your own locking" which seems conflict with the above "the user need take no lock".
Doesn't the caller need a lock to avoid concurrent accesses to the ida bitmap?

I looked at the API some more and found some flaws:
 - how does xbit_alloc communicate back which bit it allocated?
 - What if xbit_find_set() is called on a completely empty array with
   a range of 0, ULONG_MAX -- there's no invalid number to return.

We'll change it to "bool xb_find_set(.., unsigned long *result)", returning false indicates no "1" bit is found.

 - xbit_clear() can't return an error.  Neither can xbit_zero().

I found the current xbit_clear implementation only returns 0, and there isn't an error to be returned from this function. In this case, is it better to make the function "void"?

 - Need to add __must_check to various return values to discourage sloppy
   programming

So I modify the proposed API we compete with thusly:

bool xbit_test(struct xbitmap *, unsigned long bit); int __must_check
xbit_set(struct xbitmap *, unsigned long bit, gfp_t); void xbit_clear(struct
xbitmap *, unsigned long bit); int __must_check xbit_alloc(struct xbitmap *,
unsigned long *bit, gfp_t);

int __must_check xbit_fill(struct xbitmap *, unsigned long start,
                        unsigned long nbits, gfp_t); void xbit_zero(struct xbitmap *,
unsigned long start, unsigned long nbits); int __must_check
xbit_alloc_range(struct xbitmap *, unsigned long *bit,
                        unsigned long nbits, gfp_t);

bool xbit_find_clear(struct xbitmap *, unsigned long *start, unsigned long
max); bool xbit_find_set(struct xbitmap *, unsigned long *start, unsigned
long max);

(I'm a little sceptical about the API accepting 'max' for the find functions and
'nbits' in the fill/zero/alloc_range functions, but I think that matches how
people want to use it, and it matches how bitmap.h works)

Are you suggesting to rename the current xb_ APIs to the above xbit_ names (with parameter changes)? 

Why would we need xbit_alloc, which looks like ida_get_new, I think set/clear should be adequate to the current usages.

Best,
Wei