Chase, On Tue, 13 Jun 2006, Chase Venters wrote: > > 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.
I was really just using Daniel's words. I am all too aware that kernel APIs are unstable. To some it is a serious failing of Linux (particularly those involved in porting kernel modules from branded UNIX or embedded RTOS). To those whatever stability that can be offered is a boon. To those, even worse is the lack of an ABI (even for a single kernel version). > > 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). And that would be fine if we were completely agnostic toward what was included in mainline, but we are not. A particular case in point that I deal with are STREAMS modules. STREAMS continues to be forbidden from the tree. Nevertheless, STREAMS has historically provided one of the most widespread mechanisms for providing value-added drivers to branded UNIX or embedded RTOS offerings. As a result, a large body of existing drivers are cut off from the tree regardless of their licensing terms. (Note that these is seldom a question of derivation for these drivers as they are fully functioning on other operating systems: branded UNIX or embedded RTOS.) > > I'm curious now too - can you name some non-GPL non-proprietary modules we > should be concerned about? I'd think most of the possible examples (not > sure what they are) would be better off dual-licensed (one license > being GPL) and in-kernel. Any open-source license not compatible with the GPL. One that comes to mind is OpenSolaris drivers. I'm sure that there are others because there are many license that qualify as open source licenses that are incompatible with the GPL. For example, pure BSD is incompatible with GPL. 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. The second step is to jump through the hoops and over the hurdles necessary to open what has been to date proprietary code that may contain intellectual property issues across a number of organizations. In adopting a policy that hinders this process, we, instead, discourage opening of drivers and inclusion in mainline, rather than promoting it. Sorry for the rant. - 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
