[Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL

[Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL

[Dan Williams]

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.

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

[Guenter Roeck]

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.

FWIW, I personally like to have a means to say "This code shall only
be used by GPL code" for any code I contribute to the Linux kernel.
I understand that this is completely non-technical.

Guenter

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

[Greg KH]

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

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

[Laurent Pinchart]

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

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

[Dave Airlie]

On Fri, 14 Sep 2018 at 07:04, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> 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.
>

https://lwn.net/Articles/154602/

Was the original advice Linus got and raised.

Since then I think this advice has been sufficiently diluted by people
lobbying for _GPL on any/all new exports, which means that we've
probably neutered the actual usefulness of it from a legal point of
view, instead of having a discussion about why a symbol is internal
and hints at a derived work, we slapped it on a bunch of interfaces
where it probably isn't applicable.

(like refcounts had it for a while, anyone arguing that refcounts
created a derived work was definitely neither legal nor technical, it
was pure political.).

Dave.

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

[Laurent Pinchart]

Hi Dave,

On Friday, 14 September 2018 09:32:36 EEST Dave Airlie wrote:
> On Fri, 14 Sep 2018 at 07:04, Laurent Pinchart wrote:
> > 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.
> 
> https://lwn.net/Articles/154602/
> 
> Was the original advice Linus got and raised.
> 
> Since then I think this advice has been sufficiently diluted by people
> lobbying for _GPL on any/all new exports, which means that we've
> probably neutered the actual usefulness of it from a legal point of
> view, instead of having a discussion about why a symbol is internal
> and hints at a derived work, we slapped it on a bunch of interfaces
> where it probably isn't applicable.
> 
> (like refcounts had it for a while, anyone arguing that refcounts
> created a derived work was definitely neither legal nor technical, it
> was pure political.).

The argument that any module is a derived work of the kernel (at the very 
least when the module has been developed specifically for the Linux kernel) 
still hasn't been disproved, so this is a grey area as well. The argument is 
certainly political, but I don't see why it wouldn't be legal as well.

I do agree that EXPORT_SYMBOL_GPL is useful though, as it makes the intent of 
the developer clear. As a mean of telling whether an interface is internal or 
not, however, I hae my doubts.

-- 
Regards,

Laurent Pinchart

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

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]


> The argument that any module is a derived work of the kernel (at the very 
> least when the module has been developed specifically for the Linux kernel) 
> still hasn't been disproved, so this is a grey area as well. The argument is 
> certainly political, but I don't see why it wouldn't be legal as well.
> 
> I do agree that EXPORT_SYMBOL_GPL is useful though, as it makes the intent of 
> the developer clear. As a mean of telling whether an interface is internal or 
> not, however, I hae my doubts.

I fully agree.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Theodore Y. Ts'o]

On Fri, Sep 14, 2018 at 10:08:47AM +0300, Laurent Pinchart wrote:
> > 
> > https://lwn.net/Articles/154602/
> > 
> > Was the original advice Linus got and raised.
> > 
> > Since then I think this advice has been sufficiently diluted by people
> > lobbying for _GPL on any/all new exports, which means that we've
> > probably neutered the actual usefulness of it from a legal point of
> > view, instead of having a discussion about why a symbol is internal
> > and hints at a derived work, we slapped it on a bunch of interfaces
> > where it probably isn't applicable.

First of all, there's no real value (and probably some real harm) to
have programmers trying to debate questions of legal interpretation.
It would be much like asking lawyers to debug deadlocks in kernel
code.  It's not highest and best use of the people involved's talents.  :-)

Secondly, if you look very carefully at the above e-mail, the advice
didn't say anything about what criteria should be used.  In fact, the
advice was to say that instead of trying to define the criteria
(whether or not it is about internal implementation or anything else),
what was important was that there *was* a difference, and that it be
expressed explicitly in the code.


In practice, it's been mostly been up to the person who originally
implements the interface to decide whether it should be exported at
all, and if so, whether it's exported using EXPORT_SYMBOL, or
EXPORTED_SYMBOL_GPL.  I don't think there has ever been a commonly
agreed-upon set of criteria.

My personal opinion is that a good dividing line is whether the
interface is likely to stay ABI-compatible.  After all, that's the
promise that we make for userspace interfaces; once an interface is
established, it can only be changed in a way that breaks userspace for
extraordinary reasons (e.g., if it's the only way to deal with a
security issue).  And it's *clearly* understood that whether or not
you believe the GPL can infect over any interface (which is a legal
question for which the answer may vary in different jourisdictions),
that it doesn't infect across the system call boundary.

Now, obviously we don't make guarantees of absolute ABI stability of
EXPORT_SYMBOL interfaces.  But my personal take on it is that one of
the essential differences between EXPORT_SYMBOL_GPL and EXPORT_SYMBOL
is that EXPORT_SYMBOL_GPL is _more_ unstable than EXPORT_SYMBOL.

Cheers,

					- Ted

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

[Mauro Carvalho Chehab]

Em Sun, 16 Sep 2018 18:15:23 -0400
"Theodore Y. Ts'o" <tytso@mit.edu> escreveu:

> On Fri, Sep 14, 2018 at 10:08:47AM +0300, Laurent Pinchart wrote:
> > > 
> > > https://lwn.net/Articles/154602/
> > > 
> > > Was the original advice Linus got and raised.
> > > 
> > > Since then I think this advice has been sufficiently diluted by people
> > > lobbying for _GPL on any/all new exports, which means that we've
> > > probably neutered the actual usefulness of it from a legal point of
> > > view, instead of having a discussion about why a symbol is internal
> > > and hints at a derived work, we slapped it on a bunch of interfaces
> > > where it probably isn't applicable.  
> 
> First of all, there's no real value (and probably some real harm) to
> have programmers trying to debate questions of legal interpretation.
> It would be much like asking lawyers to debug deadlocks in kernel
> code.  It's not highest and best use of the people involved's talents.  :-)
> 
> Secondly, if you look very carefully at the above e-mail, the advice
> didn't say anything about what criteria should be used.  In fact, the
> advice was to say that instead of trying to define the criteria
> (whether or not it is about internal implementation or anything else),
> what was important was that there *was* a difference, and that it be
> expressed explicitly in the code.
> 
> 
> In practice, it's been mostly been up to the person who originally
> implements the interface to decide whether it should be exported at
> all, and if so, whether it's exported using EXPORT_SYMBOL, or
> EXPORTED_SYMBOL_GPL.  I don't think there has ever been a commonly
> agreed-upon set of criteria.
> 
> My personal opinion is that a good dividing line is whether the
> interface is likely to stay ABI-compatible.  After all, that's the
> promise that we make for userspace interfaces; once an interface is
> established, it can only be changed in a way that breaks userspace for
> extraordinary reasons (e.g., if it's the only way to deal with a
> security issue).  And it's *clearly* understood that whether or not
> you believe the GPL can infect over any interface (which is a legal
> question for which the answer may vary in different jourisdictions),
> that it doesn't infect across the system call boundary.
> 
> Now, obviously we don't make guarantees of absolute ABI stability of
> EXPORT_SYMBOL interfaces.  But my personal take on it is that one of
> the essential differences between EXPORT_SYMBOL_GPL and EXPORT_SYMBOL
> is that EXPORT_SYMBOL_GPL is _more_ unstable than EXPORT_SYMBOL.

I have a different view. At least on media, we have a strong preference 
for EXPORT_SYMBOL_GPL() for kAPI, as it makes clear that we do expect them 
to be used by GPL compatible modules. We don't care much for symbols that
are used inside drivers that got coded on different modules (we have a
bunch of those usually on PCI/USB devices with multiple interfaces).

We still have some symbols with EXPORTED_SYMBOL(). The reason is mainly
historic. The symbols using it there are simply the ones that were
either:

 - added to the Kernel before the advent of EXPORT_SYMBOL_GPL(),
   e. g. added before 2005;
 - during the period of time where we are getting familiar with
   EXPORT_SYMBOL_GPL(), and was discussing about its usage along the
   subsystem;
 - On places where all other symbols were already using EXPORT_SYMBOL()
   and we didn't make any major changes. So, developers just wanted
   to follow the existing module coding style and didn't want to take
   any bias with regards of their usage or not by non-GPL'd code.

A common practice there is that, when someone rewrites the implementation
of some symbol using EXPORT_SYMBOL() is to use EXPORT_SYMBOL_GPL() at
the new implementation, to make clear about our desire that media modules
should be GPL'd, but when we do simpler changes (even adding/removing
parameters at the interface), we tend not to change it[1].

So, in practice, symbols with EXPORT_SYMBOL() are more stable, but just
because them are usually for some legacy code that still works.

[1] Usually just because EXPORT_SYMBOL*() comes after the function - it
is easy to not remember touching it when we don't do a complete rewrite.

Thanks,
Mauro

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

[Steven Rostedt]

On Mon, 17 Sep 2018 07:22:50 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:

> A common practice there is that, when someone rewrites the implementation
> of some symbol using EXPORT_SYMBOL() is to use EXPORT_SYMBOL_GPL() at
> the new implementation, to make clear about our desire that media modules
> should be GPL'd, but when we do simpler changes (even adding/removing
> parameters at the interface), we tend not to change it[1].

To add to this bike-shed discussion, my view is that if the function is
unique to Linux, it should be EXPORT_SYMBOL_GPL(), and if it is a
common functionality among all operating systems (like request_irq())
then I would consider it EXPORT_SYMBOL().

The tracing infrastructure that we have is unique to Linux and thus
all functions are EXPORT_SYMBOL_GPL(). Proprietary modules can't even
add trace events without breaking that. Although they could use kprobes
and function based events (when we finish that).

-- Steve