Re: [git-pull -tip] x86: include inverse Xmas tree patches

[Thomas Gleixner]

On Sun, 29 Mar 2009, Thomas Gleixner wrote:

> On Sun, 29 Mar 2009, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > 
> > > > Personally I'd prefer alphabetic order, sorting based on length 
> > > > isn't a complete ordering.  Nearly all editors can sort 
> > > > alphabetically at the push of a key.
> > > 
> > > I'd prefer if somebody would sit down and write a tool to analyse 
> > > the include hell instead of manually shuffling crap around to 
> > > avoid trivial merge conflicts. I have cleaned up enough stuff in 
> > > the x86 merger myself where I was able to cut the number of 
> > > includes at least in half just by staring at the gcc intermediate 
> > > files. We could do better and automate the analysis so we get down 
> > > to a handful of includes instead of including the world and more.
> > 
> > I do not disagree with include file cleanups (we've done many of 
> > them in this cycle and in previous cycles), but note that the 
> > reduction in include files at the top of .c files actually increases 
> > the chance of patch conflicts: when a new include file is added by 
> > two patches to the same .c file.
> 
> Those conflicts are trivial and if we have a mechanism to anlyse
> include dependencies then we can avoid such conflicts often at all. 
> 
> Go through some of the include madness and watch the compiler reading
> the same header file ten times for a single source file compile.

I'm not against sorting the headers at all. I personally have no
preference whether it's alphabetical or length, but...

I just run the following on current git:

# FS=`find -type f`; for F in $FS; do grep -c "#include" $F; done | sort -n | uniq -c

The top 5 are:

lib/locking-selftest.c:	108 (justified as this includes all the test cases)
fs/compat_ioctl.c	 88 (maybe ok as it is the all in one kitchen sink)
arch/x86/kernel/setup.c: 76 (completely nuts)
init/main.c:		 62 (needs to be looked at)
security/selinux/hooks.c 61 (needs to be looked at, spotted at least 5 which can be removed)

1400 files have more than 20 includes. 5375 more than 10.

I think it's well justified to sit down and work on a tool which helps
us analyse and distangle that mess.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/