lkml.org 
[lkml]   [2014]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 4/7] x86, mm, pat: Add pgprot_writethrough() for WT
On Mon, 3 Nov 2014, Andy Lutomirski wrote:
> On Mon, Nov 3, 2014 at 2:53 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 3 Nov 2014, Toshi Kani wrote:
> >> On Mon, 2014-11-03 at 22:10 +0000, Elliott, Robert (Server Storage)
> >> wrote:
> >> > > +EXPORT_SYMBOL_GPL(pgprot_writethrough);
> >> > ...
> >> >
> >> > Would you be willing to use EXPORT_SYMBOL for the new
> >> > pgprot_writethrough function to provide more flexibility
> >> > for modules to utilize the new feature? In x86/mm, 18 of 60
> >> > current exports are GPL and 42 are not GPL.
> >>
> >> I simply used EXPORT_SYMBOL_GPL() since pgprot_writecombine() used
> >> it. :-) This interface is intended to be used along with
> >> remap_pfn_range() and ioremap_prot(), which are both exported with
> >> EXPORT_SYMBOL(). So, it seems reasonable to export it with
> >> EXPORT_SYMBOL() as well. I will make this change.
> >
> > NAK.
> >
> > This is new functionality and we really have no reason to give the GPL
> > circumventors access to it.
>
> I have mixed feelings about this.
>
> On the one hand, I agree with your sentiment.
>
> On the other hand, I thought that _GPL was supposed to be more about
> whether the thing using it is inherently a derived work of the Linux
> kernel. Since WT is an Intel concept, not a Linux concept, then I
> think that this is a hard argument to make.

If your argument stands then almost nothing in Linux which is related
to hardware can stand on its own as it is always dependent on the
underlying hardware. But that's not true. The software support for
that particular hardware feature is always Linux specific.

The point about derived work, which Linus made, is that the GPL might
not necessarily apply to something which was developed completely
independent of Linux in the first place and then adopted via a wrapper
layer. This applies pretty much to the odd binary graphics drivers
which got retrofitted with a Linux interface by wrapping the existing
binary blob.

We have always accomodated with this by not changing the replacement
interfaces for something with was EXPORT_SYMBOL to
EXPORT_SYMBOL_GPL. Though we have forced binary blobs away from
abusing stuff by removing such exports; google for the removal of the
init_mm export.

But that does not mean that we are obliged to expose new Linux
infrastucture which supports existing Intel hardware properties to
drivers which prefer to be closed for whatever reason.

Quite the contrary. We want to expose these new features to the fair
players. The HP driver can live with the less performant modes and if
it wants to use WT, that's none of our problems at all.

Thanks,

tglx


\
 
 \ /
  Last update: 2014-11-04 00:41    [W:0.312 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site