[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=dSm7j2Kxa5PbyKvQ=73cjVNkA6GZ3NvyZua5p@mail.gmail.com>
Date: Wed, 30 Mar 2011 23:42:26 -0700
From: Olof Johansson <olof@...om.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Bill Gatliff <bgat@...lgatliff.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Tony Lindgren <tony@...mide.com>,
David Brown <davidb@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-omap@...r.kernel.org, Nicolas Pitre <nico@...xnic.net>,
Catalin Marinas <catalin.marinas@....com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30, 2011 at 8:24 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> Check out the device tree files (*.dts) and do that same
>
> git ls-files arch/arm/ | grep gpio
>
> except do it on powerpc.
>
> See the difference?
>
> The powerpc people even wrote documentation about the thing, which is
> just above and beyond reasonable.
Powerpc does has the benefit of only having about three (active)
silicon vendors, out of which two are doing most of the arch
infrastructure work. There are more chefs in the kitchen in the ARM
world. But yeah, the arch/powerpc/platforms/* directories are tiny
compared to the ARM equivalents.
That being said: arch/ppc used to be messy too. A lot of cleanups were
done when the ppc+ppc64 -> powerpc merge happened.
Starting over on a new base would avoid some of the problems of
dealing with new incoming platforms while things are being cleaned up.
It would
decouple need to start reviewing _everything_ at the same time as as
the cleanup is underway, and would give a chance to set good examples
for how things should be handled as new platforms are brought over.
Then, when the time comes, start refusing new boards/SoCs/features on
the old subtree and have new clean stuff go directly into the new one.
Of course, main drawback is that this would duplicate the actual arch
code (the parts Russell are handling), and he is already stretched
thin as it is. That code isn't what needs the cleanup most though, so
maybe it can just be shared to start with to avoid that overhead.
-Olof
--
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