On Sun, Mar 28, 2021 at 12:23 AM Al Viro <v...@zeniv.linux.org.uk> wrote: > > On Fri, Mar 26, 2021 at 07:03:47PM +0200, Andy Shevchenko wrote: > > The bitmap.h header is used in a lot of code around the kernel. > > Besides that it includes kernel.h which sometimes makes a loop. > > How much of the kernel does *not* end up pulling kernel.h anyway, > making all subsequent includes fast no-ops? > > Realistically, any C compiler is going to recognize the case when > included file has contents of form > > #ifndef <pp-id> > #define <pp-id> <possibly empty sequence of preprocessor tokens> > <lines> > #endif > > where <lines> contain no exposed #else, #elif or #endif and > remember that subsequent includes of that file should be ignored > unless <pp-id> becomes undefined.
The problem here is not in C compiler, but in many unneeded loops that make header hell dependencies. For example, how you may move bitmap_zalloc() from C-file to the header? Currently it's impossible. And bitmap.h here is only a tip of an iceberg. kerne.h is a dump of everything that even has nothing in common at all. We may still have it, but in my new code I prefer to include only the headers that I want to use, without the bulk of unneeded kernel code. > AFAICS, on e.g. allmodconfig amd64 build it's (at most - there > might've been false positives) 131 files out of ~30000; on > defconfig it's 55 out of ~2300. How much does your patch > change that? I'm not sure I understand what you mean here. -- With Best Regards, Andy Shevchenko
