linux-kernel - Re: [PATCH] Documentation: extend use case for EXPORT_SYMBOL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150528200749.GD7232@ZenIV.linux.org.uk>
Date:	Thu, 28 May 2015 21:07:49 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc:	corbet@....net, linux-doc@...r.kernel.org,
	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: Re: [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()

On Thu, May 28, 2015 at 11:56:01AM -0700, Luis R. Rodriguez wrote:
> 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.
 
... 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-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/