All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.