lkml.org 
[lkml]   [2015]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()
On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Current documentation over use case for EXPORT_SYMBOL_GPL()
> only acknowledges functions which are "an internal implementation
> issue, and not really an interface". In practice these days
> though we have some maintainers taking on preferences to require
> all new functionality go in with EXPORT_SYMBOL_GPL().
>
> A maintainer asking developers to use EXPORT_SYMBOL_GPL()
> for new functionality tends to be a well accepted and understood
> position that maintainers can take and typically requires the
> maintainers educating contributing developers on their own
> positions and requirements.
>
> Developers who submit code to maintainers not familiar with
> these preferences as optional for new functionality need explicit
> guidence though as existing documentation does not acknowledge
> this as a valid possibility. Without this being documented some
> maintainers are reluctant to accept new functionality with
> EXPORT_SYMBOL_GPL().
>
> This extends the use case documentation for EXPORT_SYMBOL_GPL()
> to acknowledge acceptance for new functionality.

... while some of us consider that as pointless posturing and will refuse
to merge such exports regardless. It's _NOT_ a universal default; please,
do not attempt to imply otherwise. In particular, for fs/*.c I will not
accept that as valid grounds for use of EXPORT_SYMBOL_GPL.


\
 
 \ /
  Last update: 2015-05-28 22:21    [W:0.494 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site