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

Rob Landley rob at landley.net
Thu Nov 11 21:24:33 UTC 2010


On Thursday 11 November 2010 09:51:34 Jonathan Corbet wrote:
> Hi, Rob,
>
> > 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).
>
> Suffice to say I disagree with this characterization; one should not
> confuse a lack of sympathy for maintainers of out-of-tree modules with a
> deliberate attempt to make life hard.

There's a fine line between wilfully obtuse and actively obstructive.  The 
"merge your damn code already" camp has excellent engineering motivations, and 
they certainly have plausible deniability.  Having seen Greg speak on the 
topic more than once (his OLS "binary only modules are definitely illegal" talk 
comes to mind), I find it easy to ascribe deliberation to him, but I'm not a 
mind reader.

> There are other reasons for the
> internal API policy, but I doubt anybody would benefit from an extended
> discussion of them here.

I readily admit I'm over-simplifying the actions of ~300 guys over the past 
decade, and they don't all agree.  Linus's policy seems merely to be "Shut up 
and show me the code", as always, and nobody else speaks authoritatively for 
the kernel.

> One little point of fact, though:
> > Some people weren't happy with that, and decided to set up an
> > intermediate staging area to help distros coordinate their long term
> > support efforts. Adrian Bunk backported bugfixes to 2.6.16 for several
> > years:
> >
> >   http://kerneltrap.org/node/6930
> >   http://kerneltrap.org/node/7164
> >   http://lwn.net/Articles/266707/
> >
> > And when that became hopelessly out of date he moved to 2.6.27:
> >
> >   http://lkml.org/lkml/2008/10/12/2
>
> Adrian has not had a patch merged for over a year, and has never gone near
> 2.6.27.  That kernel is maintained by Greg Kroah-Hartman; it looks like
> Willy Tarreau may pick it up at some future point.

I vaguely recall a message wandering by from Adrian circa 2008 about him 
giving up on 2.6.16 and picking up a new kernel.  Doesn't mean it happened.  
For one thing, Greg's -stable series was well underway by then, and he picked 
up my suggestion of "one last -stable when the new kernel comes out so there's 
no gap between versions bugfix-wise, and anybody stuck on an old kernel can 
look at all the bugfix-only patches for the new kernels since them and try to 
backport fixes without any obvious gaps between the last 2.6.n.x and the start 
of 2.6.n+1 where bugfixes went in but weren't broken out".

It's not perfect, but -stable took a lot of the wind out of the LTS kernel 
sails.  I believe he moved on to maintaining the regression list instead (same 
motivation, different solution).

Between the busybox FAQ entry I linked to earlier, and the time based releases 
video, I hope I've documented why attempting to maintain "old stable" versions 
does not help an open source project actually do development.  For a project 
like the kernel that's got engineering effort coming out its years, yay.  They 
have spare bandwidth.

For a project like uClibc or busybox where we've had major architectural todo 
items going begging for MORE THAN FIVE YEARS now? (Yes seriously: uClibc still 
has pthreads.old, pthreads.new, _and_ NPTL hanging around unfinished.  Busybox 
has three shell implementations and none of them is a decent bash replacement, 
we've settled on hush as the way forward but it needs six months of full-time 
work before we can delete the crufty old maze of ash code, plus the testsuite 
is in three different formats and bits of it are scattered all over the 
tree...)

Pulling existing developers off of that to babysit a "dead tree" version of the 
code is not the best use of their time.  If that's what a new developer wants 
to do, they're welcome to bell that cat.

> jon

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


More information about the uClibc mailing list