Re: RFC: cleaning up the in-kernel headers

Jörn Engel
2006-07-11T22:20:52Z

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