[Mageia-dev] [fedora-arm] ARM summit at Plumbers 2011

Fri Aug 26 20:41:55 CEST 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
+