6 messages, 4 authors, 2006-06-14 · open the first message on its own page
From: Brian F. G. Bidulock <hidden>
Date: 2006-06-13 21:40:34
Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote:
This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules?
Why not? Not all non-GPL modules are proprietary. Do we lose something by making a nice stable api available to non-derived modules?
From: Chase Venters <hidden>
Date: 2006-06-13 22:00:57
On Tue, 13 Jun 2006, Brian F. G. Bidulock wrote:
Daniel, On Tue, 13 Jun 2006, Daniel Phillips wrote:quoted
This has the makings of a nice stable internal kernel api. Why do we want to provide this nice stable internal api to proprietary modules?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). 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. Thanks, Chase
From: Daniel Phillips <hidden>
Date: 2006-06-13 22:30:43
Chase Venters wrote:
can you name some non-GPL non-proprietary modules we should be concerned about?
You probably meant "non-GPL-compatible non-proprietary". If so, then by definition there are none. Regards, Daniel
From: Ben Greear <hidden>
Date: 2006-06-13 23:43:20
Chase Venters wrote:
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).
Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult! Ben -- Ben Greear [off-list ref] Candela Technologies Inc http://www.candelatech.com
From: Chase Venters <hidden>
Date: 2006-06-14 00:06:20
On Tuesday 13 June 2006 18:42, Ben Greear wrote:
Chase Venters wrote:quoted
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).Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult!
Fair enough, but if you are doing out of tree, pure GPL modules, EXPORT_SYMBOL_GPL() isn't a bad thing, is it? Don't mistake me for actually having a big opinion specifically about this socket API's usage of EXPORT_SYMBOL()... just raising some points that I think apply to these decisions in general. I don't really see a compelling reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs though... I'm trying to imagine what kind of legitimate non-GPL modules might use them.
Ben
Thanks, Chase
From: Ben Greear <hidden>
Date: 2006-06-14 00:19:52
Chase Venters wrote:
On Tuesday 13 June 2006 18:42, Ben Greear wrote:quoted
Chase Venters wrote:quoted
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).Some of us write modules for specific features that are not wanted in the mainline kernel, even though they are pure GPL. Our life is hard enough with out people setting out to deliberately make things more difficult!Fair enough, but if you are doing out of tree, pure GPL modules, EXPORT_SYMBOL_GPL() isn't a bad thing, is it? Don't mistake me for actually having a big opinion specifically about this socket API's usage of EXPORT_SYMBOL()... just raising some points that I think apply to these decisions in general. I don't really see a compelling reason for EXPORT_SYMBOL() over EXPORT_SYMBOL_GPL() on the socket APIs though... I'm trying to imagine what kind of legitimate non-GPL modules might use them.
I got to the flame war late and only saw your comment that stable API should be discouraged. That kind of thinking pisses me off because it assumes all modules out of the tree are that way because the authors want them out of the tree. I also understand that sometimes API needs to change, but please don't encourage change just to punish other authors, be they proprietary or otherwise. As for what type of EXPORT macro to use I surely don't have anything to say that hasn't been said multiple times before. Ben -- Ben Greear [off-list ref] Candela Technologies Inc http://www.candelatech.com