Dan Williams dan.j.williams at intel.com
Thu Sep 13 19:43:15 UTC 2018

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

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.

More information about the Ksummit-discuss mailing list