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

Denys Vlasenko vda.linux at googlemail.com
Fri Nov 5 22:52:42 UTC 2010


On Fri, Nov 5, 2010 at 5: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."

This makes sense.

> 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
> lot of GPL enforcement work for BusyBox, and I find frequently companies
> stuck on ridiculously old versions of BusyBox and uClibc.  I constantly
> encourage companies, as part of compliance efforts, to use more recent
> versions but I have been mostly unsuccessful in that part of the effort.
>
> Thus, I thought perhaps this "flag version" of Linux is an opportunity
> for the BusyBox and uClibc community to also pick versions that the
> embedding companies will standardize around, and thus allow the BusyBox
> and uClibc community to better dictate what versions end up being
> de-facto long-term-support versions.

I don't know. You need to ask busybox/uclibc *users*.

If they do want something like this, I certainly can
maintain such flag version of busybox.

My fear is that often the reason for using very outdated
version of busybox is different: it's simply lack of time/resources
to migrate.

There is usually a big "time to market" pressure
in embedded field, and the thinking is that migration
to newer kernel/toolchain/libc/busybox can make schedules slip.
Flag version would not help with *that*.


> BTW, both Erik and I have known Tim Bird for some time.  I can't speak
> for Erik, but I am willing to spend some time reaching out to Tim to
> coordinate this on behalf BusyBox/uClibc if there's interest from the
> BusyBox and uClibc community.

Yes, let's hear what user community says.

-- 
vda


More information about the uClibc mailing list