Date: Sun, 29 Mar 2009 01:28:31 +0100 (CET)
From: Thomas Gleixner <tglx@linutronix.de>
To: Ingo Molnar <mingo@elte.hu>
cc: "H. Peter Anvin" <hpa@kernel.org>, Sam Ravnborg <sam@ravnborg.org>,
       Alexey Dobriyan <adobriyan@gmail.com>,
       Jaswinder Singh Rajput <jaswinder@kernel.org>,
       x86 maintainers <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git-pull -tip] x86: include inverse Xmas tree patches
In-Reply-To: <alpine.LFD.2.00.0903290035390.3397@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0903290055080.3397@localhost.localdomain>
References: <1238251730.2526.2.camel@ht.satnam> <20090328150746.GA3268@x200.localdomain> <20090328190350.GA30214@uranus.ravnborg.org> <49CEA3CD.105@kernel.org> <alpine.LFD.2.00.0903290025280.3397@localhost.localdomain> <20090328233438.GA4957@elte.hu>
 <alpine.LFD.2.00.0903290035390.3397@localhost.localdomain>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2462
Lines: 57

On Sun, 29 Mar 2009, Thomas Gleixner wrote:

> On Sun, 29 Mar 2009, Ingo Molnar wrote:
> > * Thomas Gleixner <tglx@linutronix.de> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/