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 > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
