[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100603044512.GA22906@fluff.org.uk>
Date: Thu, 3 Jun 2010 05:45:12 +0100
From: Ben Dooks <ben-linux@...ff.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Kevin Hilman <khilman@...prootsystems.com>,
Daniel Walker <dwalker@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1
On Wed, Jun 02, 2010 at 06:20:09PM -0700, Linus Torvalds wrote:
>
> am, but I'm willing to do it only if I have a feeling that things are
> under control. And I'm not getting that feeling.
>
> - TWO HUNDRED THOUSAND lines of arch/arm is just pure garbage, namely the
> defconfig files. Quite frankly, anybody who calls that anything but
> pure "noise" is just misguided and being stupid.
>
> So yes, I do consider a lot of it "noise". When there's two hundred
> thousand lines of garbage, and it keeps growing without bounds, something
> needs to be done.
>
> Now, I'm actually considering just getting rid of all the 'defconfig'
> files entirely. The x86 model is sane (there's two of them, nobody likely
> uses them), but ARM and POWERPC (and to a lesser config SH and MIPS) have
> turned the whole concept into a disgusting mess.
>
> But while POWERPC has abused that thing too, in _other_ respects it has
> been much less egregious.
unfortunately there are so many different variants of the ARM
architecture that these defconfigs spring up to ensure that a base
compile for each one of them is performed. We run an autobuild which
runs through all these defconfigs and produces a report of what
happened to allow tracking of build regressions at the moment.
> So I can largely fix the defconfig mess on my own (by just using a simple
> oneliner shell script to deletes them all) but that really only fixes one
> particularly annoying symptom - not the underlying issue. We do need
> somebody to maintain the arm platform mess, and actually tries to get some
> infrastructure or something in place so that it doesn't explode.
Someone should defiently cull the older defconfigs for sepcific
machines, many of which probably don't get built for mainline.
~
> > The fact is that ARM-based devices multiply like rabbits, and there is
> > a huge amount of diversity between the various derivatives. Also,
> > support most of these devices has lived out of tree for a long time.
> > Now that we have a relatively direct path which doesn't require any
> > single person to have to understand all the mind-numbing details of
> > all of these ARM-based platforms, it has allowed us to significantly
> > improve the support for these devices upstream. Anything that is
> > common to all devices still goes through RMK.
>
> The thing is, I bet there is way more commonality still to be taken
> advantage of. And even if there isn't, we need somebody who cares, and
> doesn't just mindlessly aggregate all the crud. Somebody with the taste to
> say "ok, that's just too effin ugly, you need to fix things up"
> occasionally.
yes, there is that problem, and many of the big company players have
yet to really see the necessity in this... It has taken a while now to
convince the necessary people at Samsung that simply copying and
modifying existing driver/support is simply not going to fly.
--
Ben (ben@...ff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
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