Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thursday, 13 September 2018 23:14:06 EEST Greg KH wrote:
> 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 :)

As Guenter, I use EXPORT_SYMBOL_GPL as a political mean more than a technical 
mean. From a legal point of view it has always seemed a very grey area to me 
(especially since nobody has tested this particular in court). While a clear 
documentation would be useful to agree on a common meaning, I fear we will 
have many stakeholders trying to pull in different directions.

>From a technical point of view, this is the first time I hear about 
EXPORT_SYMBOL_GPL implying an internal implementation instead of an interface. 
The sentence has been introduced in

commit b6c17ea4eff360359d1741272028610035bb2da9
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Fri Sep 9 13:10:11 2005 -0700

    [PATCH] Update Documentation/DocBook/kernel-hacking.tmpl

without any explanation in the commit message. That seems a dubious claim to 
me, given that EXPORT_SYMBOL_GPL allows linking a module to the kernel, in 
effect creating an API.

-- 
Regards,

Laurent Pinchart