Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA

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

On Mon, Apr 01, 2019 at 10:10:33PM +0200, Rasmus Villemoes wrote:
> On 30/03/2019 19.54, Yury Norov wrote:
> > Hi Rasmus!
> > 
> >> From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> >> Sent: Saturday, March 30, 2019 12:53:51 AM
> >> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko
> >> Cc: Yury Norov; linux-kernel@vger.kernel.org
> >> Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
> >>
> >> The bitmap_remap, _bitremap, _onto and _fold functions are only used,
> >> via their node_ wrappers, in mm/mempolicy.c, which is only built for
> >> CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is
> >> global, but its only external caller is node_random() in lib/nodemask.c,
> >> which is also guarded by CONFIG_NUMA.
> > 
> > Nice catch. I think you should protect declaration of those functions
> > in include/linux/bitmap.h as well.
> 
> Yeah, well, it's not that simple, because one would also need to wrap
> the static inline __nodes_onto etc. in ifdefs. Normally, there'd be an
> #else branch defining simple static inline replacements that always fail
> or return 0, but we can't do that here.

There are enough examples of conditionally defined functions without
stubs, I don't see any problem with it. Anyways, if you don't like
doing that, moving the code and declarations to new files would help.

> So I'd prefer a simple linker
> error should any user outside NUMA ever appear. Which I very highly doubt.

Linker errors are usually less specific and much longer to obtain
at the linker-stage, which is not good.

> > I'm concerned about pollution of such a generic portion of code with
> > subsystem-related #ifdefs. Would it make more sense to move numa-specific
> > stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h,
> > or whatever)?
> 
> Well, yes, that might be better, but a lot bigger patch. One could also
> argue that bitmap.c is _already_ polluted with subsystem specific code
> (though not in the form of preprocessor directives).

I probably don't understand the argument. If we find bitmap.c polluted, we
should try clean it, right?