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

Thu Nov 11 05:27:47 UTC 2010

On Wed, Nov 10, 2010 at 04:04:06PM -0600, Rob Landley wrote:
> No, they shouldn't.
> 
> On Friday 05 November 2010 11:33:36 Bradley M. Kuhn wrote:
> > LWN.net  wrote at 18:30 (EDT) on Thursday:
> > > As a result of discussions held at two recent embedded Linux summits
> > > (and reported back to the recent Kernel Summit), the [Linux] community
> > > has decided to identify specific kernel versions as "flag versions" to
> > > try to reduce "version fragmentation". On the linux-embedded mailing
> > > list, Tim Bird ... has announced that 2.6.35 will be the first
> > > embedded flag version, and it will be supported by (at least) Sony,
> > > Google, MeeGo, and Linaro. "First, it should be explained what having
> > > a flag version means. It means that suppliers and vendors throughout
> > > the embedded industry will be encouraged to use a particular version
> > > of the kernel for software development, integration and testing. Also,
> > > industry and community developers agree to work together to maintain a
> > > long-term stable branch of the flag version of the kernel (until the
> > > next flag version is declared), in an effort to share costs and
> > > improve stability and quality."
> >
> > Tim Bird's email post that LWN is quoting from above can be seen at:
> > http://lwn.net/Articles/413341/rss
> >
> > (There's also a brief summary at
> > http://lwn.net/SubscriberLink/413036/a954ac0a143a99d9/ of the discussion
> > that took place at the embedded kernel summit on this).
> 
> 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
- 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.

I ended up porting the bare minimum needed to get kernel 2.6.34 booting
on this SoM... basically networking, serial console and a few other
basics which allowed me to have a play with the SSI driver in 2.6.34 and
create a CODEC driver (which I forked from the aic3x driver).

Getting sound going, we had a deadline approaching, and the video
drivers we had, relied on 2.6.28 quite heavily... porting Freescale's
V4L extensions and VPU to 2.6.34 would have been too much of a burdon...
instead, I wound up backporting ALSA from 2.6.34 back to 2.6.28.

As the project progressed, I found more needed features that were in the
latest kernel that the original kernel lacked.  Due to some companies
deciding to keep their port a secret ... we have needlessly had to
cobble this mess together.  Yes, it works, but I do worry about
long-term maintenance... I have a feeling these devices will be stuck at
kernel 2.6.28 for the long haul.

I did begin a port of 2.6.35-rc to these devices, however due to
financial reasons, I was not able to stay and complete this port.
Otherwise this would have likely been where development would have gone.
And I was very keen for as much of this code to go into the mainline
kernel (even if some of those in management above me weren't).

I can see why the kernel developers are going this way... but seriously,
to me it sounds too much like they're encouraging this sort of behaviour
from the big players.  I would not like to see uClibc or Busybox go down
this messy route.
-- 
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.