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

Will Newton will.newton at gmail.com
Sat Nov 6 09:09:29 UTC 2010


On Fri, Nov 5, 2010 at 4:33 PM, Bradley M. Kuhn <bkuhn at ebb.org> 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).
>
> I read this and began wondering if uClibc and BusyBox had an interest in
> doing "flag versions" in tandem with Linux.  As most of you know, I do a

I'm not sure that there's quite the same need for flag versions.
Upgrading a kernel can cause lots of subtle changes in how the system
behaves and incur a lot of effort in updating out of tree drivers,
whereas swapping a new BusyBox in has been very painless in our
experience. I don't recall whether we have ever had any issue other
than perhaps having to update the config file we use.

uClibc upgrades also tend to be pretty painless (upgrading to NPTL may
be tricky though), but probably have more potential for causing
problems.

To be honest I've experienced much larger problems with toolchain and
build system upgrades rather than uClibc and BusyBox version bumps.


More information about the uClibc mailing list