Re: Linux GPL and binary module exception clause?

[viro@parcelfarce.linux.theplanet.co.uk]

On Wed, Dec 10, 2003 at 02:36:46PM -0800, Kendall Bennett wrote:
 
> > In 2.7 we need to get the export list back to sanity.  Right now it's a
> > such a junkpile that speaking about even a relative stability for it... 
> > Not funny. 
> 
> You miss my point. I was talking about a single kernel version. For a 
> single kernel version, the ABI is both *published* and *stable*. Sure it 
> may not be what you consider a *clean* or *good* ABI, but it *IS* an ABI. 

The hell it is.  Change CONFIG_SMP or any number of other options and your
binary compatibility is toast.

> Given that it is a stable and published ABI for a single kernel version, 
> then what makes a kernel module different from a user program? The fact 

The utter lack of isolation in the former.  And that's a very practical
consideration - amount of efforts needed to tell whether any given bug is
in kernel or in an application is *way* less than for module vs. kernel.
Ditto for potential impact of changes on one side of "interface" upon the
other side.

Realistically there's no way to keep the module "API" fixed without a major
negative impact on kernel development, security and stability.  If somebody
has business model based on the expectation that this "API" will not be
changed whenever we find that useful - too bad, you can't possibly claim
that you had not been warned.

Again, lack of warranties regarding the module "API" is
	* deliberate
	* well-documented
	* older than binary-only modules
	* based on the very sound technical reasons

Live with it.  It's not going to change.

Of course some parts of the "API" are relatively stable; if nothing else,
we have in-tree drivers to consider whenever we make a change and well-behaving
3rd-party module won't take more efforts to update than a typical in-tree
driver.  But that's it - author of such module basically makes an educated
guess regarding the likeliness of change that would leave him in a bad
situation.  Generally, the deeper in kernel guts you play, the easier it
is to get burned.  And current set of exports goes very deep in said guts -
much deeper than it should have.

Anybody who does out-of-tree kernel work must understand the reality.
Modules are different from userland code in the ways that deeply affect
product cycle.  Pretending that there is no fundamental difference and
complaining about that difference signifies only one thing - lack of
basic research on part of complainers.  Don't pretend that you don't know
what you are getting into.