Re: [RFC/PATCH 1/2] in-kernel sockets API

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <Pine.LNX.4.64.0606131655580.4856@turbotaz.ourhouse>
By author:    Chase Venters <chase.venters@clientec.com>
In newsgroup: linux.dev.kernel
> >
> > Why not?  Not all non-GPL modules are proprietary.  Do we lose
> > something by making a nice stable api available to non-derived
> > modules?
> 
> Look out for that word (stable). Judging from history (and sanity), 
> arguing /in favor of/ any kind of stable module API is asking for it.
> 
> At least some of us feel like stable module APIs should be explicitly 
> discouraged, because we don't want to offer comfort for code 
> that refuses to live in the tree (since getting said code into the tree is 
> often a goal).
> 

The much bigger problem is that there is a substantial cost to
maintaining a stable API.  The VFS in Linux, for example, was
relatively stable from long before the 1.0 days until the 2.0 series.
However, in 2.1 there was a radical change -- the dcache -- which
broke every filesystem driver in fundamental ways.  This was followed
by quite a bit of instability as all the various filesystems adapted,
and sometimes fed back requirements to the original code.

This type of iterative programming is by definition forbidden if the
API is to be stable, and is substantially harder if it has to be done
in a coordinated fashion.  It took long enough as it is.

Stable *ABIs* are even worse, and are hard even for userspace to deal
with, and generally involve adding costly conversion layers.

So it is all a matter about what you expect from a "stable" API.

	-hpa