From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Yury Norov <yury.norov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Yury Norov <ynorov@marvell.com>
Subject: Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
Date: Mon, 1 Apr 2019 22:10:33 +0200 [thread overview]
Message-ID: <9ad8cb18-ba77-c659-4f44-4ab4f810f9f1@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190330185436.GA19813@yury-thinkpad>
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
next prev parent reply other threads:[~2019-04-01 20:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-30 18:54 PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA Yury Norov
2019-04-01 20:10 ` Rasmus Villemoes [this message]
2019-04-02 11:45 ` Yury Norov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9ad8cb18-ba77-c659-4f44-4ab4f810f9f1@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ynorov@marvell.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).