[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071231164624.GA1738@martell.zuzino.mipt.ru>
Date: Mon, 31 Dec 2007 19:46:24 +0300
From: Alexey Dobriyan <adobriyan@...il.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Glauber de Oliveira Costa <gcosta@...hat.com>,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
glommer@...il.com, tglx@...utronix.de, ehabkost@...hat.com,
jeremy@...p.org, avi@...ranet.com, anthony@...emonkey.ws,
virtualization@...ts.linux-foundation.org, rusty@...tcorp.com.au,
ak@...e.de, chrisw@...s-sol.org, rostedt@...dmis.org,
hpa@...or.com, zach@...are.com, roland@...hat.com
Subject: Re: [PATCH 1/2] remove __init modifier from header declaration
On Wed, Dec 19, 2007 at 11:12:36AM +0100, Ingo Molnar wrote:
> * Glauber de Oliveira Costa <gcosta@...hat.com> wrote:
>
> > This patch removes the __init modifier from an extern function
> > declaration in acpi.h.
> >
> > Besides not being strictly needed, it requires the inclusion of
> > linux/init.h, which is usually not even included directly, increasing
> > header mess by a lot.
>
> thanks, applied.
>
> btw., people have been talking about reducing the include file mess for
> nearly a decade now,
Some of us are actually doing it. ;-)
> but it didnt get that much better - at least not in
> include/asm-x86/*.h.
That's because hunting in include/linux/ is much more fruitful -- it
decreases amount of code after preprocessing for everyone. Below are
allyesconfig on x86_64 results for some kernels:
$ wc ../*.i
79018171 229433654 2049266884 ../2.6.18.i
86568111 250674099 2245115663 ../2.6.19.i
85187296 247470579 2221334183 ../2.6.20.i <===
88645422 242396928 2234855428 ../2.6.21.i
93897302 257990496 2377174442 ../2.6.22.i
98381373 268683402 2486321956 ../2.6.23.i
E.g. we can have ~1.07% decrease in cpp output despite ~126000 lines
added between .19 and .20.
> So include file dependency flattening patches would
> be more than welcome as well.
Yup! Provided they're compile-tested sufficiently well.
> (and unlike unification patches they have
> no expectation of being 100% perfect, so a natural ping-pong of fixes,
> until the changes are fully correct, would be natural.)
That way you'll never clean anything especially during merge window. ;-)
--
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/
Powered by blists - more mailing lists