From: Greg KH <greg@kroah.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL
Date: Thu, 13 Sep 2018 22:14:06 +0200 [thread overview]
Message-ID: <20180913201406.GA3554@kroah.com> (raw)
In-Reply-To: <CAPcyv4i=h-7CHpu5ZvXxPsgUOPY-B-wAjX3e5+W9vCm+o081xw@mail.gmail.com>
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
next prev parent reply other threads:[~2018-09-13 20:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 19:43 [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL Dan Williams
2018-09-13 20:05 ` Guenter Roeck
2018-09-13 20:14 ` Greg KH [this message]
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=20180913201406.GA3554@kroah.com \
--to=greg@kroah.com \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.