[PATCH/RFC] headers: drop 2 #included headers from <linux/interrupt.h>

[PATCH/RFC] headers: drop 2 #included headers from <linux/interrupt.h>

[Randy Dunlap]

From: Randy Dunlap <rdunlap@infradead.org>

It seems that <linux/interrupt.h> does not need <linux/linkage.h>
nor <linux/preempt.h>.  8 kernels builds are successful without
these 2 headers (allmodconfig, allyesconfig, allnoconfig, and
tinyconfig on both i386 and x86_64).

<linux/interrupt.h> is #included 3875 times in 4.16-rc1, so this
reduces #include processing of these 2 files by a total of 7750 times.

Since I only tested x86 builds, this needs to be tested on other
$ARCHes as well.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---

Does anyone know or see why <linux/interrupt.h> needs <linux/linkage.h> or
<linux/preempt.h>?  There are no direct uses in <linux/interrupt.h> AFAICT.

 include/linux/interrupt.h |    2 --
 1 file changed, 2 deletions(-)

--- lnx-416-rc1.orig/include/linux/interrupt.h
+++ lnx-416-rc1/include/linux/interrupt.h
@@ -4,9 +4,7 @@
 #define _LINUX_INTERRUPT_H
 
 #include <linux/kernel.h>
-#include <linux/linkage.h>
 #include <linux/bitops.h>
-#include <linux/preempt.h>
 #include <linux/cpumask.h>
 #include <linux/irqreturn.h>
 #include <linux/irqnr.h>

Re: [PATCH/RFC] headers: drop 2 #included headers from <linux/interrupt.h>

[Ingo Molnar]

* Randy Dunlap <rdunlap@infradead.org> wrote:

> Does anyone know or see why <linux/interrupt.h> needs <linux/linkage.h> or
> <linux/preempt.h>?  There are no direct uses in <linux/interrupt.h> AFAICT.

These are likely historical, plus it's a classic 'tragedy of the commons' 
scenario: it's easy to take away from the "public good" of "clean header 
dependencies" and very hard to add to it:

 - it's very easy to add a new #include line

 - it's very hard to remove one, not just due to the 2^10000 complex Kconfig
   space, but due to 99% of the developers not testing cross-arch builds
   (and we don't want to require them to do it)

 - the cost of getting the removal wrong is high (the build breaks for many 
   people who will be unhappy at the person removing the header), while the 
   benefit of the removal is low in isolation

Then apply this dynamic for more than 20 years and we get a spaghetti:

 triton:~/tip> grep -c '#include <' include/linux/*.h | sort -n -t: -k +2  | tail -20

 include/linux/device.h:15
 include/linux/ide.h:16
 include/linux/module.h:16
 include/linux/acpi.h:17
 include/linux/filter.h:17
 include/linux/init_task.h:17
 include/linux/mmzone.h:17
 include/linux/cgroup.h:18
 include/linux/nfs_fs.h:18
 include/linux/sched.h:18
 include/linux/irq.h:19
 include/linux/pci.h:19
 include/linux/perf_event.h:23
 include/linux/blkdev.h:25
 include/linux/kvm_host.h:26
 include/linux/mm.h:26
 include/linux/netdevice.h:26
 include/linux/skbuff.h:26
 include/linux/isdn.h:27
 include/linux/fs.h:39

Plus there's collateral damage as well: there's countless primitives that were 
forced into the CPP macro space because the header dependencies were too hard. 
Such code is not just harder to read and maintain, it's more fragile to macro 
substitution bugs and it's less type safe as well.

I'd argue that due to the basic human dynamics here this calls for tooling help.

In the meanwhile I've applied your patch to tip:core/headers and will do full 
build testing + fixing, should anything break.

Thanks,

	Ingo

Re: [PATCH/RFC] headers: drop 2 #included headers from <linux/interrupt.h>

[Rasmus Villemoes]

On Fri, Feb 16 2018, Ingo Molnar <mingo@kernel.org> wrote:

> * Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> Does anyone know or see why <linux/interrupt.h> needs <linux/linkage.h> or
>> <linux/preempt.h>?  There are no direct uses in <linux/interrupt.h> AFAICT.
>
> These are likely historical, plus it's a classic 'tragedy of the commons' 
> scenario: it's easy to take away from the "public good" of "clean header 
> dependencies" and very hard to add to it:
>
>  - it's very easy to add a new #include line
>
>  - it's very hard to remove one, not just due to the 2^10000 complex Kconfig
>    space, but due to 99% of the developers not testing cross-arch builds
>    (and we don't want to require them to do it)
>
>  - the cost of getting the removal wrong is high (the build breaks for many 
>    people who will be unhappy at the person removing the header), while the 
>    benefit of the removal is low in isolation
>
> Then apply this dynamic for more than 20 years and we get a spaghetti:
>
[snip]
>
> I'd argue that due to the basic human dynamics here this calls for tooling help.

I started trying to write some scripts a few years ago, but only got as
far as doing a pass over lib/ (e.g. b8b6db17) - but doing individual .c
files is never going to be enough; one really needs to eliminate
#includes from header files. But then I decided that before trying to
systematically attack that much bigger problem, I'd want some objective
metrics to see that it actually worked. Now I finally got around to
writing some scripts for that, so here's a visualization of
(the evolution of) the problem:

https://wildmoose.dk/header-bloat/

I hope to find some time soonish to polish the old programs and see if
they actually still work.

Rasmus

Re: [PATCH/RFC] headers: drop 2 #included headers from <linux/interrupt.h>

[Ingo Molnar]

* Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:

> [...] Now I finally got around to writing some scripts for that, so here's a 
> visualization of (the evolution of) the problem:
> 
> https://wildmoose.dk/header-bloat/

Nice! In particular your final conclusion is impressive and scary:

> So the typical (median) translation unit ends up including over 450 headers 
> files, making the whole TU about 200 times bigger than the .c file itself, while 
> more than 25% of the translation units get bloated to over 400 times the size of 
> the .c file.

Even with a lot of this being eliminated at fairly early compiling stages that's a 
*huge* chunk of code that needs to be parsed again and again and again and again 
...

> I hope to find some time soonish to polish the old programs and see if they 
> actually still work.

That would be lovely!

Thanks,

	Ingo

[tip:core/headers] headers: Drop two #included headers from <linux/interrupt.h>

[tip-bot for Randy Dunlap]

Commit-ID:  562c45d635ecd5c0648ceb4d4aff9bdc1ad91252
Gitweb:     https://git.kernel.org/tip/562c45d635ecd5c0648ceb4d4aff9bdc1ad91252
Author:     Randy Dunlap <rdunlap@infradead.org>
AuthorDate: Thu, 15 Feb 2018 16:49:45 -0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 16 Feb 2018 08:59:16 +0100

headers: Drop two #included headers from <linux/interrupt.h>

It seems that <linux/interrupt.h> does not need <linux/linkage.h>
nor <linux/preempt.h>.  8 kernels builds are successful without
these 2 headers (allmodconfig, allyesconfig, allnoconfig, and
tinyconfig on both i386 and x86_64).

<linux/interrupt.h> is #included 3875 times in 4.16-rc1, so this
reduces #include processing of these 2 files by a total of 7750 times.

Since I only tested x86 builds, this needs to be tested on other
$ARCHes as well.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/b24b9ec8-4970-65f5-759a-911d4ba2fcf0@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 include/linux/interrupt.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 69c2382..5426627 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -4,9 +4,7 @@
 #define _LINUX_INTERRUPT_H
 
 #include <linux/kernel.h>
-#include <linux/linkage.h>
 #include <linux/bitops.h>
-#include <linux/preempt.h>
 #include <linux/cpumask.h>
 #include <linux/irqreturn.h>
 #include <linux/irqnr.h>