From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL
Date: Sun, 16 Sep 2018 18:15:23 -0400 [thread overview]
Message-ID: <20180916221523.GB3575@thunk.org> (raw)
In-Reply-To: <7500551.ylj9XQ2o2G@avalon>
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
next prev parent reply other threads:[~2018-09-16 22:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 19:43 Dan Williams
2018-09-13 20:05 ` Guenter Roeck
2018-09-13 20:14 ` Greg KH
2018-09-13 21:04 ` Laurent Pinchart
2018-09-14 6:32 ` Dave Airlie
2018-09-14 7:08 ` Laurent Pinchart
2018-09-16 12:58 ` Wolfram Sang
2018-09-16 22:15 ` Theodore Y. Ts'o [this message]
2018-09-17 10:22 ` Mauro Carvalho Chehab
2018-09-18 13:35 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180916221523.GB3575@thunk.org \
--to=tytso@mit.edu \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox