[Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL
Greg KH
greg at kroah.com
Thu Sep 13 20:14:06 UTC 2018
On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote:
> Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in
> Documentation/ is:
>
> "It implies that the function is considered an internal implementation
> issue, and not really an interface."
>
> The topics for a Maintainer Summit discussion are:
>
> 1/ The criteria "is considered an internal implementation issue" is
> sufficiently vague and seems to lead to arbitrary and subjective
> decisions by individual developers. Are there some objective technical
> criteria we can apply? For example, the symbol consumes other
> EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide
> state / policy, or the symbol leaks internal implementation details
> that are more unstable than typical EXPORT_SYMBOL apis. Any additional
> subjective criteria to consider? For example, it would be better for
> long term health of Linux if the consumers of a given API had the
> EXPORT_SYMBOL_GPL-related encouragement to get their code upstream.
>
> 2/ With expanded criteria in hand the question then becomes what are
> the considerations for changing an existing symbol between
> EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and
> unwanted to set down hard rules, but a list of considerations that a
> change proposal needs to address would at least help guide such
> discussions.
>
> Not being a lawyer, I'm less interested in legal concerns, and more
> the technical, code maintenance, and health of the kernel aspects of
> what EXPORT_SYMBOL_GPL influences.
>
> Note, I am not available to travel to Edinburgh to lead this discussion.
Nice topic, I like it!
Being the one who used this symbol first (I think, maybe I am wrong),
I'd be glad to lead this if others think it would be a good thing to
formally document.
And yes, I'm in the "let's document this thing somehow to keep
maintainers from getting stuck in the middle" camp :)
thanks,
greg k-h
More information about the Ksummit-discuss
mailing list