linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it
Date: Fri, 2 Aug 2013 14:24:19 +0100	[thread overview]
Message-ID: <20130802132419.GO23006@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130802124130.GI7656@atomide.com>

On Fri, Aug 02, 2013 at 05:41:31AM -0700, Tony Lindgren wrote:
> Oh and thinking about it a bit more, this issue is mostly with the
> device drivers implementing frameworks, not the device drivers
> using the frameworks. Things like clocks, regulators, muxes etc where
> an almost similar instance is repeated tens or hundreds of times for
> each SoC.

That is where it helps to have a strong maintainer for a subsystem who
has the guts to refuse to accept stuff which is similar to existing
implementations and insist that existing implementations are either
adapted or reused.

It's all very well someone coming along and writing a "generic" set of
implementations (like tglx did for the IRQ subsystem) but unless there's
a motivation for people to use the generic stuff (such as... you won't
get your code in if you don't use the provided generics unless you can
provide a very good reasoned argument) then people are just going to
write their own code time and time again.

It's just like how the clocksources have gone.  We now have multiple
implementations of how to read a counter which ticks at a specific
rate.  You wouldn't think that I wrote drivers/clocksource/mmio.c which
can handle all of these simple 32-bit/16-bit up/down counter cases.
Again, the problem is there is no strong reviewer there who looks over
every addition and says "no, use the generic stuff".

That's the basic problem here: the review, and people saying "no" to
new stuff doing the same as generic stuff.

  reply	other threads:[~2013-08-02 13:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31  7:38 [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it Tony Lindgren
2013-07-31 12:33 ` [Ksummit-2013-discuss] " Greg KH
2013-07-31 13:53   ` Jason Cooper
2013-08-02  7:55     ` Tony Lindgren
2013-08-02  7:53   ` Tony Lindgren
2013-08-02  8:03     ` Felipe Balbi
2013-08-02  8:26       ` Tony Lindgren
2013-08-02  8:11     ` Greg KH
2013-08-02  8:39       ` Tony Lindgren
2013-08-02 12:41     ` Tony Lindgren
2013-08-02 13:24       ` Russell King - ARM Linux [this message]
2013-08-05  6:30         ` Tony Lindgren
2013-08-02 19:57     ` Mike Turquette
2013-08-05  6:36       ` Tony Lindgren
2013-07-31 15:21 ` Mel Gorman
2013-08-02  8:13   ` Tony Lindgren
2013-08-02 21:31     ` Matt Sealey
2013-08-03  5:30       ` Olof Johansson
2013-08-05  6:43         ` Tony Lindgren

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=20130802132419.GO23006@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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).