Re: [PATCH 1/2] lib/bitmap: move bitmap allocators for device to linux/device.h

[Yury Norov <yury.norov@gmail.com>]

On Sun, Oct 08, 2023 at 06:53:49AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 07, 2023 at 04:35:09PM -0700, Yury Norov wrote:
> > The allocators are simple wrappers around bitmap_{alloc,free}().
> > So move them from bitmap to device sources.
> 
> No, they belong in the bitmap.h file, as they are devm_* versions of the
> same functions in this file.  They don't belong in the device.h file.

OK then. I don't thing that the functions are anything wrong, and
don't want to 'get rid of them' in any way.

But could you please elaborate? I'm not too familiar to devm_* things,
and to me devm_alloc/free() look similar to e.g.
vfio_dma_bitmap_alloc_all() or iova_bitmap_alloc(), which allocate
memory for bitmap + do some other initialization things.

And they all reside in corresponding subsystems. Why devm differs? 
 
> > Similarly to other device wrappers, turn them to static inlines
> > and place in header.
> 
> Why do these need to be inline functions?

Because they are small. devm_bitmap_free() and devm_bitmap_zalloc()
are pure one-line wrappers, and devm_bimap_alloc() is a 2 function
calls followed by conditionals, which is similar  to
__devm_add_action_or_reset() or devm_kmalloc_array() in the same file,
and much less than some other inliners in the source tree.

In my plans, I want to move bitmap_{z,}alloc/free() to linux/bitmap.h,
and that way devm_bitmap_alloc() together with other users would be
propagated __kmalloc_array() by compiler without generating pretty
useless call/ret's, and benefit from compile-time optimizations if
__builtin_constant_p() hits.

Maybe it's worth to do in this series.

Thanks,
Yury