linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	tomi.valkeinen@ti.com, airlied@linux.ie,
	linux-fbdev@vger.kernel.org, luto@amacapital.net,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	xen-devel@lists.xensource.com, "Toshi Kani" <toshi.kani@hp.com>,
	"Suresh Siddha" <sbsiddha@gmail.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Juergen Gross" <jgross@suse.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Dave Airlie" <airlied@redhat.com>,
	"Antonino Daplas" <adaplas@gmail.com>,
	"Jean-Christophe Plagniol-Villard" <plagnioj@jcrosoft.com>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	venkatesh.pallipadi@intel.com,
	"Stefan Bader" <stefan.bader@canonical.com>,
	"Ville Syrjälä" <syrjala@sci.fi>, "Mel Gorman" <mgorman@suse.de>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Borislav Petkov" <bp@suse.de>,
	"Davidlohr Bueso" <dbueso@suse.de>,
	konrad.wilk@oracle.com, ville.syrjala@linux.intel.com,
	david.vrabel@citrix.com, jbeulich@suse.com,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v6 1/4] pci: add pci_iomap_wc() variants
Date: Fri, 22 May 2015 02:23:41 +0200	[thread overview]
Message-ID: <20150522002341.GM23057@wotan.suse.de> (raw)
In-Reply-To: <20150521223321.GG32152@google.com>

On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> 
> I tentatively put this (and the rest of the series) on a pci/resource
> branch.  I'm hoping you'll propose some clarification about
> EXPORT_SYMBOL_GPL().

EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
only run that code. So for instance although we have "Dual BSD/GPL"
tags for modules pure "BSD" tags do not exist for module tags and
cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
who do believe tha at run time all kernel modules are GPL [1] [2].
And to be precise even though the FSF may claim a list of licenses
are GPL-compatible we cannot rely on this list alone for our own
goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
discuss this on lkml [2].

In the past when I've tried to try to clarify EXPORT_SYMBOL_GPL()
requirements, implications, its been said that its best to leave
some things as-is [3] and let attorneys figure things out. In so
far as to what exactly it is and can be used for requires legal
attorney review, but the question of derivative work certainly
comes up [4]. Now folks companies seem to want to obviously use
and abuse our symbols despite of all the things above, for instance
Red Hat once tried to change an EXPORT_SYMBOL_GPL() to
EXPORT_SYMBOL() [5]. Obviously that didn't go so well, and some
folks went off on a good rant about this [6].

What developers do and accept varies, I'm not going into pointing
out specifics and I do not wnat to do homework for folks who wish
to abuse things further, but by no means should a developer be
nack'd entry to new code if their functionality is not replacing
old one [9]. In this case this is new functionality. Also in terms
of preference:

"nobody has said that symbols exported with plain EXPORT_SYMBOL() can be freely
used by proprietary code; indeed, a number of developers claim that all (or
nearly all) loadable modules are derived products of the kernel regardless of
whether they use GPL-only symbols or not" [7].

And spot on:

"In general, the kernel community has long worked to maintain a vague and scary
ambiguity around the legal status of proprietary modules while being unwilling
to attempt to ban such modules outright." [7].

Now, a few maintainers insist on tons of new symbols to be EXPORT_SYMBOL_GPL()
though proactively [8] [9] and the reasons vary, I just happen to also write my
code to be perfectly clear with my goals and intent and you are the first to
ask me to reconsider this, even if you do make me use EXPORT_SYMBOL() my intent
and goal does not change, as with others. No code I ever write should be used
by proprietary shit, and I hope to convince others of the importance to do this
as well.

> In the meantime, I tried to make the changelog a bit more concise, as
> below.  Let me know if I omitted something essential.  We still have URLs
> for the discussion for the fine points.

Looks good.

[0] https://lkml.org/lkml/2012/4/7/102
[1] https://lkml.org/lkml/2012/4/8/71
[2] https://lkml.org/lkml/2012/4/8/71
[3] https://lkml.org/lkml/2009/6/1/385
[4] https://lkml.org/lkml/2009/6/1/376
[5] https://lkml.org/lkml/2012/4/20/328
[6] https://plus.google.com/+AlanCoxLinux/posts/D2feRNc6R4d
[7] https://lwn.net/Articles/603131/
[8] https://lwn.net/Articles/603139/
[9] https://lkml.org/lkml/2015/2/26/379

  Luis

  reply	other threads:[~2015-05-22  0:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 23:08 [PATCH v6 0/4] pci: add and use pci_iomap_wc() Luis R. Rodriguez
2015-05-20 23:08 ` [PATCH v6 1/4] pci: add pci_iomap_wc() variants Luis R. Rodriguez
2015-05-21 22:26   ` Bjorn Helgaas
2015-05-21 22:33   ` Bjorn Helgaas
2015-05-22  0:23     ` Luis R. Rodriguez [this message]
2015-05-26 17:40       ` Bjorn Helgaas
2015-05-27 20:04         ` Luis R. Rodriguez
2015-05-29  0:36           ` Luis R. Rodriguez
2015-05-29  5:57             ` Tomi Valkeinen
2015-05-29 19:24               ` Luis R. Rodriguez
2015-06-16 19:16             ` Luis R. Rodriguez
2015-06-16 22:20               ` Bjorn Helgaas
2015-06-19 21:06                 ` Luis R. Rodriguez
2015-06-19 21:18                   ` Bjorn Helgaas
2015-05-20 23:08 ` [PATCH v6 2/4] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc() Luis R. Rodriguez
2015-05-20 23:08 ` [PATCH v6 3/4] video: fbdev: s3fb: " Luis R. Rodriguez
2015-05-20 23:08 ` [PATCH v6 4/4] video: fbdev: vt8623fb: " Luis R. Rodriguez

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=20150522002341.GM23057@wotan.suse.de \
    --to=mcgrof@suse.com \
    --cc=adaplas@gmail.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=bp@suse.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.vrabel@citrix.com \
    --cc=dbueso@suse.de \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@do-not-panic.com \
    --cc=mgorman@suse.de \
    --cc=mingo@elte.hu \
    --cc=mst@redhat.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=roger.pau@citrix.com \
    --cc=sbsiddha@gmail.com \
    --cc=stefan.bader@canonical.com \
    --cc=syrjala@sci.fi \
    --cc=tglx@linutronix.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.com \
    --cc=vbabka@suse.cz \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    --cc=xen-devel@lists.xensource.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;
as well as URLs for NNTP newsgroup(s).