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

Al Viro
2023-12-06T00:55:52Z

On Wed, Dec 06, 2023 at 08:46:50AM +0900, Greg KH wrote:
> > >
> > > But of course, it doesn't always hold true, there are a few minor
> > > exceptions, but they are rare.
> >
> > $ grep -r \\#include lib | grep asm
> >
> > shows quite a few exceptions, and just in lib/.
> >
> > For example, lib/math/int_log.c includes asm/bug.h. Is that a case
> > where lib/math/int_log.c should be #include 'ing linux/bug.h rather
> > than asm/bug.h?
>
> Probably yes, but we don't normally go back and take coding style fixes
> for old files like this as it doesn't make much sense to do so.
>
> But, if you are cleaning up the headers for large portions with the goal
> of faster builds, that's a good reason.

FWIW, the most common (by far - about 13% of such includes, over drivers/, fs/,
mm/, net/ and sound/) is asm/unaligned.h.

The next are asm/io.h (10%), asm/byteorder.h (6%), asm/irq.h (5%), asm/div64.h (3%),
asm/page.h and asm/dma.h (2% each). The rest is below that (the next is a bit over
1%).

In fs/* unaligned.h is again the top one (37 out of 139), followed by
byteorder.h (30 out of 139), div64.h (12), page.h (10) and then comes random
shite - I do not believe that fs/coda/psdev.c might have a legitimate
reason to pull asm/io.h, for one thing...