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

[Stuart Longland]

[Dropping uClibc as I am not subscribed]

On Thu, Nov 11, 2010 at 07:57:30AM +0200, Baruch Siach wrote:
> 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.

Indeed.  The advertising literature stated "Linux 2.6".  As the people
who made this decision and came up with the design were not programmers,
this is understandable... but yes, it was a big mistake.

They also made some design decisions that I myself would not want to
repeat.

> 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.

Indeed... this is where it's often hard to determine what the true
status is.  Keeping so much behind closed doors, it's hard to get a look
in.

> > - 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.

Well, I knew TI did like to keep their privates private... I saw that
with MSP430 (anyone tried to code for one of those on non-x86 Linux?)
...but I digress...

What's more, the driver they were offering was for kernel 2.6.22... so I
would have had to forward-port that to 2.6.34, then backport to 2.6.28.
It would have been an even bigger mess.

They need to somehow get the message that these silly games are *not
helping*.  Having had this experience, I now very carefully check for
this kind of nonsense, and I'll be voting with my wallet.
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.