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

[Rob Landley]

On Thursday 11 November 2010 09:07:31 Mark Brown wrote:
> On Wed, Nov 10, 2010 at 04:04:06PM -0600, Rob Landley wrote:
> > 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).
>
> Pretty much all of this, especially the bit about the motivations behind
> the API changes that do occur, is inaccurate.

"Pretty much all of this is inaccurate."

So you're saying the linux developers don't hate binary only modules?  They 
like the idea of a stable internal API?  Driver and filesystem patches can 
regularly expect to apply unmodified to multiple versions?  Somewhere in the 
release notes or some such there's a checklist of changes you'd need to make 
to update an out of tree driver to the next kernel version?

I'd love to find that last one.  http://lwn.net/Articles/2.6-kernel-api/ was 
last updated over a year ago, and never claimed to be complete.  Neither 
http://kernelnewbies.org/LinuxChanges nor http://www.h-
online.com/open/features/What-s-new-in-Linux-2-6-36-1103009.html are 
specifically about API changes.  (Also, none of these are actually part of the 
kernel release process.)

I'm not a mind reader, and can only give my impression/opinion of their 
motivations for doing stuff.  There's one closed-mouthed linus, a dozen 
argumentative lieutenants, and hundreds of active maintainers: they don't have 
a single monolithic motivation.  Heck, last I checked (um, 2006?) Linus still 
had a strong pesonal dislike for Richard Stallman, but continued to use the 
FSF's compiler.

I also agree the kernel developers have good engineering justifications for 
what they do.  I'm not trying to accuse them of anything.  But "I've been paid 
to do open source" and "I do open source to get paid" are not equivalent 
statements, the world contains more subtleties than that.

My point was merely "the kernel has its own issues that do not apply to uClibc 
or busybox".  One of those things is different political undercurrents.  (And 
yes the embedded world has its own.  You can't explain _our_ users or 
developers' behavior entirely in terms of engineering either.)

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