Re: RFC: cleaning up the in-kernel headers

[Jörn Engel <joern@wohnheim.fh-wedel.de>]

On Tue, 11 July 2006 15:01:21 -0700, H. Peter Anvin wrote:
> Jörn Engel wrote:
> >
> >Not too bad in principle, but there were two problems I couldn't
> >solve:
> >1. One of the goals should be to make a compile faster, not slower.
> >Adding further includes hardly helps.
> >2. It is practically impossible to test every possible combination of
> >#ifdefs in the various headers pulled in.
> >
> 
> #1 I doubt the time taken to look at include files that are #ifndef'd in 
> their entirety is significant (I think there is special code in gcc to 
> handle this case fast.)

Quoting Dave Jones from a few mails down the thread:
It did make a noticable difference to compiles, though I forget the
exact numbers.   Should be in the list archives somewhere.
I have vague recollection that it shaved off around 20-30s, though
my memory is fuzzy.

> #2 is actually a non-issue.  If each file is usable standalone (and have 
> a multiple inclusion guard), then the include order shouldn't matter. 
> Not that one can't create contrived cases where it would matter, but one 
> can't solve every problem...

#2 was not about include order, but about things like CONFIG_SMP,
different arches, etc.  As Russell King showed, breaking Arm is easier
than many people think.

Jörn

-- 
Don't patch bad code, rewrite it.
-- Kernigham and Pike, according to Rusty
-
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/