[lkml]   [2006]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC/PATCH 1/2] in-kernel sockets API
Chase Venters wrote:
> On Tuesday 13 June 2006 18:42, Ben Greear wrote:
>>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
> 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 Greear <>
Candela Technologies Inc

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-14 02:22    [W:0.050 / U:1.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site