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

Mark Brown broonie at sirena.org.uk
Fri Nov 12 15:59:04 UTC 2010


On Thu, Nov 11, 2010 at 04:01:08PM -0600, Rob Landley wrote:
> 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.

> 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 

Your original text quoted above says that the changes that are
introduced during development are part of a deliberate attempt to
frustrate developers of out of tree modules with an active effort (eg,
"go out of their way...") to frustrate them.  For the overwhelming
majority of kernel developers it would be more accuarate to say that
they simply don't care about out of tree developers and that just don't
figure in any of the consideration that goes into non-ABI changes.

> 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?

git log is the only comprehensive thing you're going to get, though LWN
does make some effort to cover global things.

> 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 
That's not how the quoted paragraph reads.


More information about the uClibc mailing list