linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kevin Hilman <khilman@deeprootsystems.com>,
	Daniel Walker <dwalker@codeaurora.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [GIT PULL] ARM MSM updates for 2.6.35-rc1
Date: Thu, 3 Jun 2010 05:45:12 +0100	[thread overview]
Message-ID: <20100603044512.GA22906@fluff.org.uk> (raw)
In-Reply-To: <alpine.LFD.2.00.1006021803350.8175@i5.linux-foundation.org>

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@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

  parent reply	other threads:[~2010-06-03  4:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-27 21:52 [GIT PULL] ARM MSM updates for 2.6.35-rc1 Daniel Walker
2010-06-02 20:50 ` Daniel Walker
2010-06-02 21:27   ` Linus Torvalds
2010-06-02 21:39     ` Linus Torvalds
2010-06-02 21:56       ` Daniel Walker
2010-06-02 22:30     ` Daniel Walker
2010-06-02 23:27     ` Kevin Hilman
2010-06-03  1:20       ` Linus Torvalds
2010-06-03  3:44         ` Michael Ellerman
2010-06-03  4:26           ` Linus Torvalds
2010-06-03 16:11             ` Tony Lindgren
2010-06-04  5:34             ` Eric Miao
2010-06-03  4:45         ` Ben Dooks [this message]
2010-06-03  5:36         ` Ben Dooks
2010-06-04  8:27         ` Vincent Sanders

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100603044512.GA22906@fluff.org.uk \
    --to=ben-linux@fluff.org \
    --cc=dwalker@codeaurora.org \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).