summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuis R. Rodriguez <mcgrof@suse.com>2015-05-28 21:56:01 +0300
committerJonathan Corbet <corbet@lwn.net>2015-06-05 01:39:46 +0300
commit582ed8d51e2b6cb8a168c94852bca482685c2509 (patch)
tree2648f71698ada2dbe86e97aa109b968da36db78c
parentbde1b29420d71a17d87332db8e20229f251d6c14 (diff)
downloadlinux-582ed8d51e2b6cb8a168c94852bca482685c2509.tar.xz
Documentation: extend use case for EXPORT_SYMBOL_GPL()
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. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> [jc: wording tweaked with permission] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
-rw-r--r--Documentation/DocBook/kernel-hacking.tmpl2
1 files changed, 2 insertions, 0 deletions
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index e84f09467cd7..589b40cc5eb5 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -954,6 +954,8 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<function>MODULE_LICENSE()</function> that specifies a GPL
compatible license. It implies that the function is considered
an internal implementation issue, and not really an interface.
+ Some maintainers and developers may however
+ require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
</para>
</sect1>
</chapter>