All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Luis R. Rodriguez" <mcgrof@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	bp@suse.de, arnd@arndb.de, luto@amacapital.net,
	akpm@linux-foundation.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com,
	mst@redhat.com, toshi.kani@hp.com, linux-fbdev@vger.kernel.org,
	xen-devel@lists.xensource.com, benh@kernel.crashing.org
Subject: Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Wed, 22 Jul 2015 08:43:48 -0500	[thread overview]
Message-ID: <20150722134348.GA10966@google.com> (raw)
In-Reply-To: <20150722083844.GA14626@gmail.com>

Hi Ingo,

On Wed, Jul 22, 2015 at 10:38:45AM +0200, Ingo Molnar wrote:
> 
> * Bjorn Helgaas <bhelgaas@google.com> wrote:
> 
> > > > > Let me know if these are OK or if there are any questions.
> > > > > 
> > > > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> > > > 
> > > > Ingo,
> > > > 
> > > > Just a friendly reminder. Let me know if there are any issues or questions.
> > > 
> > > It would be nice to get an Acked-by from Bjorn for the PCI API bits.
> > 
> > I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is fine 
> > (although I might have named it pci_ioremap_bar_wc() for consistency).
> > 
> > I declined to merge or ack them myself because they're obvious extensions of 
> > pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be exported 
> > the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
> 
> Huh? AFAICS pci_ioremap_bar() has been a _GPL export for a long time:
> ...
> (ioremap_wc() is EXPORT_SYMBOL() mostly by accident, it's the odd one out.)

You're right, I was mistaken about pci_ioremap_bar().  But I'm not
convinced yet that ioremap_wc() is the odd one out.  All the interfaces I
found, with the exception of ioremap_uc() on x86 and pci_ioremap_bar(), are
EXPORT_SYMBOL(), even the _wc and _wt flavors.

> Also, FWIIW: I personally got essentially zero feedback and help from proprietary 
> binary kernel module vendors in the past couple of years as x86 maintainer, 
> despite a fair chunk of kernel crashes reported on distro kernels occuring in 
> them...
> 
> Based on that very negative experience, when we introduce something as complex and 
> as critical as new caching APIs, the last thing I want is to have obscure bugs in 
> binary modules I cannot fix in any reasonable fashion. So even if the parent APIs 
> of new APIs weren't already _GPL exports (as in this case), I'd export them as 
> _GPL in this case.
> 
> > I think using EXPORT_SYMBOL_GPL to express individual political aims rather than 
> > as a hint about what might be derived work makes us look like zealots, and 
> > that's not my style.
> 
> As far as I'm concerned it's a pure technological choice: I don't want to export 
> certain types of hard to fix and critical functionality to drivers that I cannot 
> then fix.

That's a good argument that I hadn't heard before (or possibly it was there
and I missed it).  It would be stronger still if we could change the parent
APIs similarly.  If a proprietary driver can't use pci_ioremap_wc() because
it's exported _GPL, it's trivial to use ioremap_wc() directly.

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <bhelgaas@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Luis R. Rodriguez" <mcgrof@suse.com>,
	"Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	bp@suse.de, arnd@arndb.de, luto@amacapital.net,
	akpm@linux-foundation.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, tomi.valkeinen@ti.com,
	mst@redhat.com, toshi.kani@hp.com, linux-fbdev@vger.kernel.org,
	xen-devel@lists.xensource.com, benh@kernel.crashing.org
Subject: Re: [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()
Date: Wed, 22 Jul 2015 13:43:48 +0000	[thread overview]
Message-ID: <20150722134348.GA10966@google.com> (raw)
In-Reply-To: <20150722083844.GA14626@gmail.com>

Hi Ingo,

On Wed, Jul 22, 2015 at 10:38:45AM +0200, Ingo Molnar wrote:
> 
> * Bjorn Helgaas <bhelgaas@google.com> wrote:
> 
> > > > > Let me know if these are OK or if there are any questions.
> > > > > 
> > > > > [0] http://lkml.kernel.org/r/20150625204703.GC4898@pd.tnic
> > > > > [1] http://lkml.kernel.org/r/20150707095012.GQ7021@wotan.suse.de
> > > > 
> > > > Ingo,
> > > > 
> > > > Just a friendly reminder. Let me know if there are any issues or questions.
> > > 
> > > It would be nice to get an Acked-by from Bjorn for the PCI API bits.
> > 
> > I think the actual code of pci_ioremap_wc() and pci_ioremap_wc_bar() is fine 
> > (although I might have named it pci_ioremap_bar_wc() for consistency).
> > 
> > I declined to merge or ack them myself because they're obvious extensions of 
> > pci_ioremap() and pci_ioremap_bar(), and I would prefer that they be exported 
> > the same way, i.e., with EXPORT_SYMBOL(), not EXPORT_SYMBOL_GPL().
> 
> Huh? AFAICS pci_ioremap_bar() has been a _GPL export for a long time:
> ...
> (ioremap_wc() is EXPORT_SYMBOL() mostly by accident, it's the odd one out.)

You're right, I was mistaken about pci_ioremap_bar().  But I'm not
convinced yet that ioremap_wc() is the odd one out.  All the interfaces I
found, with the exception of ioremap_uc() on x86 and pci_ioremap_bar(), are
EXPORT_SYMBOL(), even the _wc and _wt flavors.

> Also, FWIIW: I personally got essentially zero feedback and help from proprietary 
> binary kernel module vendors in the past couple of years as x86 maintainer, 
> despite a fair chunk of kernel crashes reported on distro kernels occuring in 
> them...
> 
> Based on that very negative experience, when we introduce something as complex and 
> as critical as new caching APIs, the last thing I want is to have obscure bugs in 
> binary modules I cannot fix in any reasonable fashion. So even if the parent APIs 
> of new APIs weren't already _GPL exports (as in this case), I'd export them as 
> _GPL in this case.
> 
> > I think using EXPORT_SYMBOL_GPL to express individual political aims rather than 
> > as a hint about what might be derived work makes us look like zealots, and 
> > that's not my style.
> 
> As far as I'm concerned it's a pure technological choice: I don't want to export 
> certain types of hard to fix and critical functionality to drivers that I cannot 
> then fix.

That's a good argument that I hadn't heard before (or possibly it was there
and I missed it).  It would be stronger still if we could change the parent
APIs similarly.  If a proprietary driver can't use pci_ioremap_wc() because
it's exported _GPL, it's trivial to use ioremap_wc() directly.

Bjorn

  reply	other threads:[~2015-07-22 13:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09  1:54 [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54 ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 1/8] PCI: Add pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 2/8] drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 3/8] drivers/video/fbdev/kyrofb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 4/8] drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 5/8] PCI: Add pci_iomap_wc() variants Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 6/8] drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc() Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 7/8] drivers/video/fbdev/s3fb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54 ` [PATCH v9 8/8] drivers/video/fbdev/vt8623fb: " Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-09  1:54   ` Luis R. Rodriguez
2015-07-17 20:29 ` [PATCH v9 0/8] pci: add pci_iomap_wc() and pci_ioremap_wc_bar() Luis R. Rodriguez
2015-07-17 20:29   ` Luis R. Rodriguez
2015-07-21  8:52   ` Ingo Molnar
2015-07-21  8:52     ` Ingo Molnar
2015-07-21  8:52     ` Ingo Molnar
2015-07-21 13:21     ` Bjorn Helgaas
2015-07-21 13:21       ` Bjorn Helgaas
2015-07-22  8:38       ` Ingo Molnar
2015-07-22  8:38         ` Ingo Molnar
2015-07-22 13:43         ` Bjorn Helgaas [this message]
2015-07-22 13:43           ` Bjorn Helgaas
2015-08-06 21:45           ` Luis R. Rodriguez
2015-08-06 21:45             ` 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=20150722134348.GA10966@google.com \
    --to=bhelgaas@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=bp@suse.de \
    --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=mcgrof@suse.com \
    --cc=mingo@kernel.org \
    --cc=mst@redhat.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.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 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.