[Arm-netbook] Fwd: Auto-discard notification

[Luke Kenneth Casson Leighton]

From: Bill Gatliff <bgat at billgatliff.com>
To: Russell King - ARM Linux <linux at arm.linux.org.uk>
Date: Fri, 26 Aug 2011 13:41:55 -0500
Subject: Re: [fedora-arm] ARM summit at Plumbers 2011
Russell:

On Fri, Aug 26, 2011 at 11:35 AM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote:
>> As such refactoring consolidated larger and larger chunks of kernel
>> code, new designs would gravitate towards those consolidated
>> implementations because they would be the dominant references.
>
> Don't bet on it.  That's not how it works (unfortunately.)

I wasn't being clear.

The Linux community isn't large enough to dictate to ARM SoC designers
how their hardware should work--- mostly because the "Linux community"
doesn't buy chips, corporations do.  And it has been my experience
that the parts of corporations that negotiate deals for the hardware
aren't populated with the developers of the drivers for said hardware.

What I meant was that as new hardware becomes available, if we have
strong driver models then driver authors will adopt those APIs rather
than inventing their own.

I'm thinking about GPIO before gpiolib, for example.  Or the current
state of PWM.

> This "need to be different" is so heavily embedded in the mindset of the
> hardware people that I doubt "providing consolidated implementations"
> will make the blind bit of difference.  I doubt that hardware people
> coming up with these abominations even care one bit about what's in
> the kernel.

I don't routinely see a "need to be different" as existing strictly
for its' own sake, even with the hardware guys.  Rather, I see a lot
of developers (hardware and software) that are so consumed with their
own requirements and deadlines that they don't get the chance to step
back and see the bigger picture.  The resulting fragmentation is a
symptom, not the disease itself.

And honestly, some of the fragmentation is a really good thing.  I
love how Atmel does their GPIO controllers on the SAM-series parts,
for example.  The SODR and CODR registers are a godsend for concurrent
code.  We wouldn't have such treats if everybody did things the same
way.

So I'm generally ambivalent to the hardware situation.  But that
doesn't mean that the software has to be equally fragmented.  In fact,
I think the hardware situation necessitates that we pay particular
attention to NOT fragmenting the drivers for said hardware.  Gpiolib
proves that is possible, something I didn't think I would find myself
saying when David Brownell started his effort.  I'm glad he proved me
wrong.



b.g.
--
Bill Gatliff
bgat at billgatliff.com