[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1103310855450.29543@asgard.lang.hm>
Date: Thu, 31 Mar 2011 09:03:28 -0700 (PDT)
From: david@...g.hm
To: Russell King - ARM Linux <linux@....linux.org.uk>
cc: Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...xnic.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>,
Tony Lindgren <tony@...mide.com>,
David Brown <davidb@...eaurora.org>,
lkml <linux-kernel@...r.kernel.org>,
linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
Catalin Marinas <catalin.marinas@....com>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
> On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
>> Having strong, effective platform abstractions inside the kernel really helps
>> even if the hardware space itself is inevitably fragmented: both powerpc and
>> x86 has shown that. Until you realize and appreciate that you really have not
>> understood the problem i think.
>
> No, I think it is the other way around. Folk like me and Nicolas over
> the last ten years have put considerable amounts of effort into trying
> to keep the ARM support code as clean and maintainable as possible.
In this case I owe you and Nicolas an apology.
I think that part of the issue is that when Linus points out a problem,
the response isn't "we agree and are working on it, here's what we are
doing", instead it seems to be mostly "there is no problem, this is just
because there is so much variation in ARM"
Linus does look at the code he pulls, if he is pulling changesets that are
described as consolodations and cleanups, he won't be whining about code
churn.
but if he is just pulling chnagesets that are described as "addsupport for
board X" or "modify defconfig defaults" he is going to complain.
it's not the total amount of code, and it's not even the total amount of
change to the code that's the issue. It's that the changes are conflicting
with each other (due to things like central config tables that multiple
people are updating in different ways) and the same files getting modified
frequently, many times in ways that don't seem to have a clear direction
(defconfigs for example)
David Lang
--
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