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

[Chase Venters <chase.venters@clientec.com>]

On Tuesday 13 June 2006 19:30, Brian F. G. Bidulock wrote:

> Yes, and the long list of open source licenses listed on the FSF website
> as incompatible with the GPL.

Conceded, I suppose. The usage of EXPORT_SYMBOL() though tends to be for the 
reason of enabling drivers to offer functionality to the kernel -- not for 
people who want to turn the kernel into applications. (Consider for example 
how netfilter is exposed as GPL. You can build applications [routers] out of 
it, but in that case you're doing a work derived off of Linux, and you should 
be abiding by its GPL licensing terms)

> > Then would offering a 'stable API in disguise' not be a disaster and an
> > irritation to these people? If the kernel doesn't specify that an
> > in-kernel interface is stable, then there is no reason to expect it to
> > be. It might not change, but there won't be too much sympathy for
> > out-of-tree users if it does. The kernel comes with big warnings about
> > the lack of a stable API for a reason.
>
> In fact most core kernel facilities (spin lock, memory caches, character
> and block device interface, even core file system) have had a very stable
> API (way back to early 2.4 kernels).  An in fact most of them are derived
> from some variant or precursor to UNIX.  For example, memory caches are a
> Sun Solaris concept.

I'm not advocating changing the API for no reason / just to piss off out of 
tree developers. I'm just trying to make clear that in these cases, 'stable' 
is just an observation -- not something you can count on.

> It is the lack of an ABI that is most frustrating to these users.

And the presence of an ABI would be _very_ frustrating to core developers. Not 
only would these people suffer, everyone would -- developer time would be 
wasted dealing with cruft, and forward progress would be slowed.

> > > Another thing to consider is that the first step for many organizations
> > > in opening a driver under GPL is to release a proprietary module that
> > > at least first works.
> >
> > If the driver is an old-tech Linux port, then it seems there isn't too
> > much stopping them from doing this today (aside from the fact that some
> > people think proprietary modules are murky anyway). In this case, we
> > don't want a stable API/ABI, because then we leave them with little
> > incentive to open the code.
>
> "old-tech"?  No, these are high-tech drivers supported by commercial RTOS,
> from which Linux stands to benefit.  And, by not allowing these
> organizations to take the first step (generate a workable Linux driver)
> such a policy provides them little incentive to ever move the driver to
> Linux, and cuts them off from opening it.

Perhaps another term may have been more appropriate. What I mean by 'old tech' 
is more 'existing code' -- ie, something you would port. 

And these organizations _are_ afforded the opportunity to take the first step 
-- that's why interfaces critical to drivers are currently EXPORT_SYMBOL().

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

> > We're not as perfect as I wish we were. But the lack of stable API (dead
> > horse) is something that is fairly well established and understood. I
> > think most people feel that the cost-benefit analysis, for Linux anyway,
> > strongly favors no stable API.
>
> Well, the lack of a stable ABI is well known.  The API is largely stable
> (but not sacrosanctly so) for the major reason that changing it within a
> large code base is difficult and error prone at best.

Perhaps, but calling it 'stable' in any sense other than idle observation is a 
disaster, because the idea leads to pain and suffering when you do have a 
major reason to change the API.

Thanks,
Chase