On Tue, Dec 5, 2023 at 1:24 PM Andrew Morton <a...@linux-foundation.org> wrote: > > On Tue, 5 Dec 2023 13:14:16 -0800 Nick Desaulniers <ndesaulni...@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.
Hmm...how does one know that linux/bits.h is the higher-level include of asm/bitsperlong.h? Do we mention these conventions anywhere under Documentation? > > 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). The tooling Tanzir is working on does wrap IWYU, and does support such mapping (of 'low level' to 'high level' headers; more so, if it recommends X you can override to suggest Y instead). arch/nios/ also doesn't provide a bug.h, which this patch is suggesting we include directly. I guess the same goes for asm/rwonce.h. -- Thanks, ~Nick Desaulniers
