[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1432839361-10308-1-git-send-email-mcgrof@do-not-panic.com>
Date: Thu, 28 May 2015 11:56:01 -0700
From: "Luis R. Rodriguez" <mcgrof@...not-panic.com>
To: corbet@....net, linux-doc@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, mingo@...e.hu,
gnomes@...rguk.ukuu.org.uk, gregkh@...uxfoundation.org,
jkosina@...e.cz, bhelgaas@...gle.com, linux-pci@...r.kernel.org,
xen-devel@...ts.xenproject.org, bp@...e.de,
"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()
From: "Luis R. Rodriguez" <mcgrof@...e.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.
Cc: Jonathan Corbet <corbet@....net>
Cc: linux-doc@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Signed-off-by: Luis R. Rodriguez <mcgrof@...e.com>
---
Documentation/DocBook/kernel-hacking.tmpl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index e84f094..19e0c88 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -954,6 +954,8 @@ printk(KERN_INFO "my ip: %pI4\n", &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 have a preference to
+ require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
</para>
</sect1>
</chapter>
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists