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