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 09:07:49PM +0100, Al Viro wrote:
> 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.

Can you elaborate why, for those maintainers not aware of such positions?

> It's _NOT_ a universal default; please, do not attempt to imply otherwise.

Indeed, the documentation does not try to do that.

> In particular, for fs/*.c I will not
> accept that as valid grounds for use of EXPORT_SYMBOL_GPL.

Understood.

Luis


\
 
 \ /
  Last update: 2015-05-29 00:01    [W:0.060 / U:10.900 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site