[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080101165732.GB3488@elte.hu>
Date: Tue, 1 Jan 2008 17:57:32 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Alexey Dobriyan <adobriyan@...il.com>
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
* Alexey Dobriyan <adobriyan@...il.com> wrote:
> > 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. ;-)
sorry, this was really not meant to slight your contributions in this
area in any way :-) I'm just judging by the spaghetti still hanging
around in asm-x86/*.h, and the 'fun' we have with paravirt and its type
dependencies - and the periodic messups we have with macros. (and many
macros are not inlines due to ugly dependencies.)
> > So include file dependency flattening patches would be more than
> > welcome as well.
>
> Yup! Provided they're compile-tested sufficiently well.
as long as it builds/boots on your box with a single convenient .config
of yours, we can stick such patches into x86.git and work out all the
build failures it might cause.
> > (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.
> ;-)
hm, what do you mean?
Ingo
--
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