On Fri, Feb 16 2018, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > * Randy Dunlap <rdunlap@xxxxxxxxxxxxx> 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
