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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Mar 2009 01:28:31 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Ingo Molnar <mingo@...e.hu>
cc:	"H. Peter Anvin" <hpa@...nel.org>, Sam Ravnborg <sam@...nborg.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git-pull -tip] x86: include inverse Xmas tree patches

On Sun, 29 Mar 2009, Thomas Gleixner wrote:

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