From: Dan Williams <dan.j.williams@intel.com>
To: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL
Date: Thu, 13 Sep 2018 12:43:15 -0700 [thread overview]
Message-ID: <CAPcyv4i=h-7CHpu5ZvXxPsgUOPY-B-wAjX3e5+W9vCm+o081xw@mail.gmail.com> (raw)
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.
next reply other threads:[~2018-09-13 19:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 19:43 Dan Williams [this message]
2018-09-13 20:05 ` [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 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
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='CAPcyv4i=h-7CHpu5ZvXxPsgUOPY-B-wAjX3e5+W9vCm+o081xw@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).