On 30/03/2019 19.54, Yury Norov wrote: > Hi Rasmus! > >> From: Rasmus Villemoes <[email protected]> >> Sent: Saturday, March 30, 2019 12:53:51 AM >> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko >> Cc: Yury Norov; [email protected] >> 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. So I'd prefer a simple linker error should any user outside NUMA ever appear. Which I very highly doubt. > 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). Dunno, I'll defer to Andrew's judgment. Rasmus
