lkml.org 
[lkml]   [2019]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
From
Date
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. 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

\
 
 \ /
  Last update: 2019-04-01 22:11    [W:0.040 / U:17.596 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site