Re: [PATCH] lib/string: shrink lib/string.i via IWYU

Andrew Morton
2023-12-05T21:24:58Z

On Tue, 5 Dec 2023 13:14:16 -0800 Nick Desaulniers <ndesaulniers@google.com> wrote:

> >
> > The preferred way to import bit-fiddling stuff is to include
> > <linux/bits.h>. Under the hood this may include asm/bitsperlong.h. Or
> > it may not, depending on Kconfig settings (particularly architecture).
> >
>
> Just triple checking my understanding; it looks like
> include/linux/bits.h unconditionally includes asm/bitsperlong.h (which
> is implemented per arch) most of which seem to include
> asm-generic/bitsperlong.h.
>
> include/linux/bits.h also defines a few macros (BIT_MASK, BIT_WORD,
> BITS_PER_BYTE, GENMASK, etc). If lib/string.c is not using any of
> those, why can't we go straight to #including asm/bitsperlong.h? That
> should resolve to the arch specific impl which may include
> asm-generic/bitsperlong.h?

It's just a general rule. If the higher-level include is present, use
that. Because of the above, plus I guess things might change in the
future.

We've been getting better about irregular asm/include files.

But bits.h is a poor example. A better case to study is spinlock.h.
If this tool recommended including asm/spinlock.h then that won't work
on any architecture which doesn't implement SMP (there is no
arch/nios2/include/asm/spinlock.h).