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

["Brian F. G. Bidulock" <bidulock@openss7.org>]

Chase,

On Tue, 13 Jun 2006, Chase Venters wrote:
> 
> > I don't think that it is fair to say that an unstable API/ABI, in of
> > itself, provides an incentive to open an existing proprietary driver.
> 
> Sure it does, depending on your perspective and what you're willing to 
> consider. The lack of a stable API/ABI means that if you don't want to have 
> to do work tracking the kernel, you should push to have your drivers merged.
> 

More work must be done to track the kernel before they are merged, thus
purposeless API changes, or unnecessary use of EXPORT_SYMBOL_GPL impedes
merging

Not all useful kernel modules will nor should be merged GPL or not.

I think that a policy that intentionally makes it hard for proprietary
modules to be developed defeats the purpose of ultimate opening and merging.
It might end up causing something like iBCS, LinuxABI, SVR D3DK, or ODI to
flourish obviating the principal goal.

The interface currently under discussion is ultimately derived from the BSD
socket-protocol interface, and IMHO should be EXPORT_SYMBOL instead of
EXPORT_SYMBOL_GPL, if only because using _GPL serves no purpose here and can
be defeated with 3 or 4 obvious (and probably existing) lines of code.  I
wrote similar wrappers for STREAMS TPI to Linux NET4 interface instead of
using pointers directly quite a few years ago.  I doubt I was the first.
There is nothing really so novel here that it deserves _GPL.