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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
