Should BusyBox and uClibc also make a "flag version" like Embedded Linux?

[Baruch Siach]

Hi Stuart,

On Thu, Nov 11, 2010 at 03:27:47PM +1000, Stuart Longland wrote:
> On Wed, Nov 10, 2010 at 04:04:06PM -0600, Rob Landley wrote:
> > No, they shouldn't.

[snip]

> > Neither uClibc nor busybox has even 1% of the churn of the linux kernel.
> > 
> > Look: Linux has to deal with binary only modules, which the developers hate.  
> > To compensate for this, they go out of their way to avoid having a stable 
> > internal API (which could argualy be used as a copyright barrier and thus 
> > prevent the modules from being derived works of the Linux kernel to which 
> > GPLv2 must apply).  To avoid this, they break internal compatability 
> > essentially every release.  They go out of their way _not_ to make forward-
> > porting modules easy (otherwise they'd have a checklist each release saying do 
> > this this and this, and you'll be up to date).
> 
> Indeed... and a lot of these companies like playing these silly
> proprietary games wherein they don't want to contribute the code back to
> the community.  It's apparently licensed as "GPL", but it's kept under
> lock-and-key and one has to jump through several hoops to see it.
> 
> Yes, I'm looking at you, Texas Instruments and Freescale.
> 
> The upshot is that those of us who are developing software, and by
> extension the end user, loose out... because the features they were
> hoping for don't exist in the prehistoric kernel supplied.
> 
> Case in point:
> - A company I was working on wanted to develop an intercom station
> - They chose to use the Linux kernel
> - They evaluated a number of Linux-capable SoC devices and settled on
>   a SoM based on the Freescale i.MX27
> - For the audio CODEC, they settled on the TI TLV320AIC3204

But they have made these two decisions before checking the state of mainline 
kernel support. Big mistake.

For projects I'm involved in I do my best to influence hardware decisions 
based on the current (or near term projected) Linux kernel support.

> - The SoM used a customised kernel based on Linux 2.6.28... it is only
>   made available to those who have purchased the modules.  Latest
>   mainline kernel was 2.6.34 at the time.
> - The chosen audio CODEC used I2S for audio transfer.  2.6.28 did not
>   support I2S on the i.MX27... but 2.6.34 did.
> 
> The decision to make then was a choice between:
> - Backport the SSI driver to 2.6.28
> - Forward port the custom patchset to 2.6.34
> 
> We also didn't have a CODEC driver... but TI were happy to supply us
> with one... with a catch... their license prohibited the execution of
> that code on non-TI processors.  So it was useless to us... we had to
> spend time developing that too.

Wow. I was under the impression that TI are good Linux community members. At 
least judging from the volume of company sponsored activity around their SoCs 
(OMAP, DaVinci). Maybe the CODEC devision is different in this regard. I see 
the same distinction between the Freescale ARM (i.MX) and PowerPC departments.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -