[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [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@xxxxxxxx>
> > 
> > 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
> > 
> > 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.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.