[PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Andy Lutomirski]

The FPU is not a super-Linuxy internal detail, so remove the _GPL
from its export.  Without something like this patch, it's impossible
for even highly license-respecting non-GPL modules to use the FPU,
which seems silly to me.  After all, the FPU is a CPU feature, not
really a kernel feature at all.

Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc:: Borislav Petkov <bp@suse.de>
Cc: Rik van Riel <riel@surriel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Nicolai Stange <nstange@suse.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Cc: stable@vger.kernel.org
Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---

This fixes a genuine annoyance for ZFS on Linux.  Regardless of what
one may think about the people who distribute ZFS on Linux
*binaries*, as far as I know, the source and the users who build it
themselves are entirely respectful of everyone's license.  I have no
problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
using it for things that aren't fundamentally Linux internals.

 arch/x86/kernel/fpu/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2e5003fef51a..8de5687a470d 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -127,14 +127,14 @@ void kernel_fpu_begin(void)
 	preempt_disable();
 	__kernel_fpu_begin();
 }
-EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+EXPORT_SYMBOL(kernel_fpu_begin);
 
 void kernel_fpu_end(void)
 {
 	__kernel_fpu_end();
 	preempt_enable();
 }
-EXPORT_SYMBOL_GPL(kernel_fpu_end);
+EXPORT_SYMBOL(kernel_fpu_end);
 
 /*
  * Save the FPU state (mark it for reload if necessary):
-- 
2.21.0

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Sebastian Andrzej Siewior]

On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> The FPU is not a super-Linuxy internal detail, so remove the _GPL
> from its export.  Without something like this patch, it's impossible
> for even highly license-respecting non-GPL modules to use the FPU,
> which seems silly to me.  After all, the FPU is a CPU feature, not
> really a kernel feature at all.
> 
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc:: Borislav Petkov <bp@suse.de>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Nicolai Stange <nstange@suse.de>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krčmář <rkrcmar@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: x86@kernel.org
> Cc: stable@vger.kernel.org
> Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> 
> This fixes a genuine annoyance for ZFS on Linux.  Regardless of what
> one may think about the people who distribute ZFS on Linux
> *binaries*, as far as I know, the source and the users who build it
> themselves are entirely respectful of everyone's license.  I have no
> problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
> using it for things that aren't fundamentally Linux internals.

Please don't start this. We have everything _GPL that is used for FPU
related code and only a few functions are exported because KVM needs it.
Also with the recent FPU rework it is much easier to get this wrong so I
would not want for any OOT code to mess with it.

And again: It does not change whether or not ZFS can be used on Linux
(excluding the license issue). They simply can't use crc32 with their
SSE assembly and this is it.

Sebastian

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Andy Lutomirski]

On Thu, May 2, 2019 at 8:41 AM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> > The FPU is not a super-Linuxy internal detail, so remove the _GPL
> > from its export.  Without something like this patch, it's impossible
> > for even highly license-respecting non-GPL modules to use the FPU,
> > which seems silly to me.  After all, the FPU is a CPU feature, not
> > really a kernel feature at all.
> >
> > Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Cc:: Borislav Petkov <bp@suse.de>
> > Cc: Rik van Riel <riel@surriel.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Dave Hansen <dave.hansen@linux.intel.com>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Nicolai Stange <nstange@suse.de>
> > Cc: Paolo Bonzini <pbonzini@redhat.com>
> > Cc: Radim Krčmář <rkrcmar@redhat.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: x86@kernel.org
> > Cc: stable@vger.kernel.org
> > Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
> > Signed-off-by: Andy Lutomirski <luto@kernel.org>
> > ---
> >
> > This fixes a genuine annoyance for ZFS on Linux.  Regardless of what
> > one may think about the people who distribute ZFS on Linux
> > *binaries*, as far as I know, the source and the users who build it
> > themselves are entirely respectful of everyone's license.  I have no
> > problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
> > using it for things that aren't fundamentally Linux internals.
>
> Please don't start this. We have everything _GPL that is used for FPU
> related code and only a few functions are exported because KVM needs it.
> Also with the recent FPU rework it is much easier to get this wrong so I
> would not want for any OOT code to mess with it.
>

I'm not saying that we should export things for ZFS's benefit.  But,
as far as I know, _GPL means "this interface is sufficiently specific
to Linux details that we think that any user must be a derived work".
I don't think that kernel_fpu_begin() is an example of that.

--Andy

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Borislav Petkov]

On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
> I'm not saying that we should export things for ZFS's benefit.  But,
> as far as I know, _GPL means "this interface is sufficiently specific
> to Linux details that we think that any user must be a derived work".
> I don't think that kernel_fpu_begin() is an example of that.

But it is sufficiently specific. It is present on x86 and s390 only -
other arches don't have it.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Paolo Bonzini]

On 02/05/19 10:55, Borislav Petkov wrote:
> On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
>> I'm not saying that we should export things for ZFS's benefit.  But,
>> as far as I know, _GPL means "this interface is sufficiently specific
>> to Linux details that we think that any user must be a derived work".
>> I don't think that kernel_fpu_begin() is an example of that.
> But it is sufficiently specific. It is present on x86 and s390 only -
> other arches don't have it.

This is not what is meant usually by "sufficiently specific to Linux
details".  The questions to ask are:

1) Is it a Linux-only thing to run FPU or SIMD code in the kernel?  The
answer is clearly no.

2) Is the API form tied to Linux's implementation of the FPU?  I'd argue
that a simple begin/end pair is not (for example, on Windows you just
xsave at the beginning and xrstor at the end).

So I totally agree with Andy on this.


Your observation that the API only exists on x86 and s390 has no bearing
to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
It's just that SIMD code is so arch-specific that nobody has bothered
unifying the namings (or, nobody considers the different names a problem
at all).

Paolo

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Borislav Petkov]

On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
> Your observation that the API only exists on x86 and s390 has no bearing
> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
> It's just that SIMD code is so arch-specific that nobody has bothered
> unifying the namings (or, nobody considers the different names a problem
> at all).

This is actually proving my point: there wasn't any real agreement on
what interfaces should be immutable so that out-of-tree code can use
them and us guaranteeing they won't change. Instead, it was a random
thing that just happened.

So if you have to use them in some out-of-tree module, you'd have to
do arch-specific hackery, obviously, because each arch does different
things.

So what happened is that out-of-tree module simply grabbed them and now
when we change our implementation, we broke it. And I care about this
why exactly?

So let me cut to the chase: you and Andy are arguing about what exactly?

* We should support out-of-tree code in general?

* We should support out-of-tree code if/when <fill in the specifics which
out-of-tree code should be supported by Linux and which not>?

* We should be free to change kernel interfaces and implementation as
we see fit, without paying attention to some out-of-tree, probably
license-incompatible, maybe even proprietary code? (I don't think it is
that, though).

* Something else I've missed.

So before we waste any more time with this, let's agree on the rules
first: do we support out-of-tree code and if so, how much and to what
degree?

This keeps happening so I think we should write it all down so that it
is crystal clear to all parties involved what can and cannot be done.
And then when we all agree, we can enforce those rules and then act
accordingly when changing implementations.

Maybe it is written down somewhere but I haven't found it yet so if you
do, pls point me to it.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Andy Lutomirski]

> On May 3, 2019, at 11:07 AM, Borislav Petkov <bp@alien8.de> wrote:
> 
>> On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
>> Your observation that the API only exists on x86 and s390 has no bearing
>> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
>> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
>> It's just that SIMD code is so arch-specific that nobody has bothered
>> unifying the namings (or, nobody considers the different names a problem
>> at all).
> 
> This is actually proving my point: there wasn't any real agreement on
> what interfaces should be immutable so that out-of-tree code can use
> them and us guaranteeing they won't change. Instead, it was a random
> thing that just happened.
> 

I don’t think I or has said we should try to make these interfaces immutable. What I’m saying is that, since we’re exporting the symbol anyway and it’s not particularly Linuxy, that we shouldn’t say that only *GPL* out-of-tree modules may use it.  It seems like anyone who wants to put the effort into tracking which kernel has which symbols and is willing to accept the utter instability of the interface may use it.

So if we ever unexport the symbol entirely, I won’t object.  I object to what I consider to be the inappropriate claim that it’s a *GPL* export.

(I actually hope we unexport it once simd_get() and friends land — they’re a much better API, and we should migrate over to it.)

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Borislav Petkov]

On Fri, May 03, 2019 at 11:54:54AM -0700, Andy Lutomirski wrote:
> I don’t think I or has said we should try to make these interfaces
> immutable.

How else would you have a stable interface for OOT modules? If at all,
that is.

> What I’m saying is that, since we’re exporting the symbol anyway
> and it’s not particularly Linuxy, that we shouldn’t say that only
> *GPL* out-of-tree modules may use it. It seems like anyone who wants
> to put the effort into tracking which kernel has which symbols and is
> willing to accept the utter instability of the interface may use it.

This is just silly: when we change it next time, it'll be the same
crying again. No, we don't want to do that. This keeps happening with
all kinds of symbols being exported and unexported.

> So if we ever unexport the symbol entirely, I won’t object.

Yah, and you'll break them again. That's just unnecesary pain each time.

> I object to what I consider to be the inappropriate claim that it’s
> a *GPL* export.

Yes, that is the problem. Jiri alluded to it too - I don't think it is
clear to people involved - me included - what exports should be done and
how. And what assurances - if any - we're giving.

> (I actually hope we unexport it once simd_get() and friends land —
> they’re a much better API, and we should migrate over to it.)

Same problem as above with those.

That's why we need some sort of an explicit ruling all sides will adhere
to.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Jiri Kosina]

On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:

> Please don't start this. We have everything _GPL that is used for FPU
> related code and only a few functions are exported because KVM needs it.

That's not completely true. There are a lot of static inlines out there, 
which basically made it possible for external modules to use FPU (in some 
way) when they had kernel_fpu_[begin|end]() available.

I personally don't care about ZFS a tiny little bit; but in general, the 
current situation with _GPL and non-_GPL exports is simply not nice. It's 
not really about licensing (despite the name), it's about 'internal vs 
external', which noone is probably able to define properly.

If it would be strictly about license compatibility, that'd at least make 
us somewhat deterministic.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Ingo Molnar]

* Jiri Kosina <jikos@kernel.org> wrote:

> On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> 
> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
> 
> That's not completely true. There are a lot of static inlines out there, 
> which basically made it possible for external modules to use FPU (in some 
> way) when they had kernel_fpu_[begin|end]() available.
> 
> I personally don't care about ZFS a tiny little bit; but in general, the 
> current situation with _GPL and non-_GPL exports is simply not nice. It's 
> not really about licensing (despite the name), it's about 'internal vs 
> external', which noone is probably able to define properly.

But that's exactly what licensing *IS* about: the argument is that 
'internal' interfaces are clear proof that the binary module is actually 
a derived work of the kernel.

(Using regular exported symbols might still make a binary module derived 
work, but it's less clear-cut.)

So don't be complicit with binary module authors who try to circumvent 
the GPL by offloading the actual license violation to the end user ...

> If it would be strictly about license compatibility, that'd at least 
> make us somewhat deterministic.

License compatibility is rarely deterministic to begin with, there's a 
lot of grey area. Adding _GPL increases the likelihood that the module 
using it has to be covered by the GPL too. In fact behavior of binary 
modules seems to confirm that legal expectation: very few binary modules 
are trying to circumvent _GPL symbols by ignoring the _GPL attribute.

Anyway, in terms of _GPL exports the policy has always been that if a 
major author of the code asks for a symbol to be _GPL, then it should be 
so, even if other authors have a different judgement.

Thanks,

	Ingo

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Sebastian Gottschall]

Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
> * Jiri Kosina <jikos@kernel.org> wrote:
>
>> On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
>>
>>> Please don't start this. We have everything _GPL that is used for FPU
>>> related code and only a few functions are exported because KVM needs it.
>> That's not completely true. There are a lot of static inlines out there,
>> which basically made it possible for external modules to use FPU (in some
>> way) when they had kernel_fpu_[begin|end]() available.
>>
>> I personally don't care about ZFS a tiny little bit; but in general, the
>> current situation with _GPL and non-_GPL exports is simply not nice. It's
>> not really about licensing (despite the name), it's about 'internal vs
>> external', which noone is probably able to define properly.
> But that's exactly what licensing *IS* about: the argument is that
> 'internal' interfaces are clear proof that the binary module is actually
> a derived work of the kernel.
Using fpu code in kernel space in a kernel module is a derived work of 
the kernel itself?
dont get me wrong, but this is absurd. i mean you limit the use of cpu 
instructions. the use
of cpu instructions should be free of any licensing issue. i would even 
argument you are violating
the license of the cpu ower given to the kernel by executing it, by 
restricting its use for no reason


Sebastian

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Greg KH]

On Sat, May 04, 2019 at 04:28:17AM +0200, Sebastian Gottschall wrote:
> 
> Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
> > * Jiri Kosina <jikos@kernel.org> wrote:
> > 
> > > On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> > > 
> > > > Please don't start this. We have everything _GPL that is used for FPU
> > > > related code and only a few functions are exported because KVM needs it.
> > > That's not completely true. There are a lot of static inlines out there,
> > > which basically made it possible for external modules to use FPU (in some
> > > way) when they had kernel_fpu_[begin|end]() available.
> > > 
> > > I personally don't care about ZFS a tiny little bit; but in general, the
> > > current situation with _GPL and non-_GPL exports is simply not nice. It's
> > > not really about licensing (despite the name), it's about 'internal vs
> > > external', which noone is probably able to define properly.
> > But that's exactly what licensing *IS* about: the argument is that
> > 'internal' interfaces are clear proof that the binary module is actually
> > a derived work of the kernel.
> Using fpu code in kernel space in a kernel module is a derived work of the
> kernel itself?
> dont get me wrong, but this is absurd. i mean you limit the use of cpu
> instructions. the use
> of cpu instructions should be free of any licensing issue. i would even
> argument you are violating
> the license of the cpu ower given to the kernel by executing it, by
> restricting its use for no reason

Now you are just being crazy, please go talk to a lawyer about how the
GPL actually works.

If Andy wants to change the symbol of what he wrote from
EXPORT_SYMBOL_GPL() to EXPORT_SYMBOL(), that's fine, it's his option.
Any loony discussion about if this is actually a licensing issue or not
needs to just go to /dev/null

As homework, everyone please go read this:
	http://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.pdf
and remember that the license of the Linux kernel is GPLv2.

Now where's the "kill this thread" option on mutt so I don't have to see
any more of this nonsense...

greg k-h

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Rik van Riel]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Sat, 2019-05-04 at 04:28 +0200, Sebastian Gottschall wrote:

> Using fpu code in kernel space in a kernel module is a derived work
> of 
> the kernel itself?
> dont get me wrong, but this is absurd. i mean you limit the use of
> cpu 
> instructions. the use
> of cpu instructions should be free of any licensing issue. i would
> even 
> argument you are violating
> the license of the cpu ower given to the kernel by executing it, by 
> restricting its use for no reason

Using FPU code in kernel space in a kernel module
does not require the use of kernel_fpu_begin/end().

The kernel module could simply disable preemption,
save the FPU registers, use the FPU, restore the
FPU registers, and reenable preemption.

However, using kernel_fpu_begin/end() does get that
module some nice optimizations that are specific to
Linux.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Jiri Kosina]

On Sun, 5 May 2019, Rik van Riel wrote:

> > Using fpu code in kernel space in a kernel module is a derived work of 
> > the kernel itself? dont get me wrong, but this is absurd. i mean you 
> > limit the use of cpu instructions. the use of cpu instructions should 
> > be free of any licensing issue. i would even argument you are 
> > violating the license of the cpu ower given to the kernel by executing 
> > it, by restricting its use for no reason
> 
> Using FPU code in kernel space in a kernel module does not require the 
> use of kernel_fpu_begin/end().
> 
> The kernel module could simply disable preemption, save the FPU 
> registers, use the FPU, restore the FPU registers, and reenable 
> preemption.

That means the module basically reimplemented kernel_fpu_begin/end() in 
its whole (not getting the further optimizations implemented by the 
kernel, sure). And therefore I sort of don't see the point of "hiding" it.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Jiri Kosina]

On Fri, 3 May 2019, Jiri Kosina wrote:

> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
> 
> That's not completely true. There are a lot of static inlines out there, 
> which basically made it possible for external modules to use FPU (in some 
> way) when they had kernel_fpu_[begin|end]() available.

... any for many uses that's really the only thing that's needed.

	kernel_fpu_beign();
	asm volatile ("some SSE2/AVX/... math");
	kernel_fpu_end();

No other bits of the FPU API, so there is no way of getting anything wrong 
because of FPU intrinsic details really.

So I don't really see a problem with Andy's patch. If we want to annoy 
external non-GPL modules as much as possible, sure, that's for a separate 
discussion though (and I am sure many people would agree to that). 
Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would 
be a good start I guess :)

-- 
Jiri Kosina
SUSE Labs

RE: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[David Laight]

...
> So I don't really see a problem with Andy's patch. If we want to annoy
> external non-GPL modules as much as possible, sure, that's for a separate
> discussion though (and I am sure many people would agree to that).
> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
> be a good start I guess :)

As a writer on an external non-GPL module I'd point out:
1 - Even if we wanted to 'upstream' our code it is very specific
    and wouldn't really be wanted/accepted.
    Even if accepted it would always be excluded from builds.
2 - It would take man-years to make it meet the kernel code guidelines
    and to make it portable (from x86).
    It also contains conditionals because it gets build for windows.
    I don't like a lot of it.
3 - Almost all the calls to kernel functions are through a 'wrapper'
    file that is compiled on the target system.
    About the only functions that are directly called are ones like memcpy().
4 - It wouldn't be that hard, and would still be GPLv2 if we built
    two loadable modules, one GPL and one non-GPL and put all our
    wrapper functions in the GPL one.
    We'd still need a small wrapper for the non-GPL module, but while
    Non-GPL modules are supported at all it wouldn't be much work.
5 - The continual tweaks for new kernel versions keep us in a job!

Some of the _GPL exports are a PITA:
- we can't reference count network namespaces (without creating a socket).
- we can't reference count 'pid' structures making sending signals tricky.
- I thing the PCIe error handling functions that we ought to be using
  are GPL.

At the moment we've not needed the fpu :-)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Sebastian Gottschall]

Am 07.05.2019 um 12:31 schrieb David Laight:
> ...
>> So I don't really see a problem with Andy's patch. If we want to annoy
>> external non-GPL modules as much as possible, sure, that's for a separate
>> discussion though (and I am sure many people would agree to that).
>> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
>> be a good start I guess :)
> As a writer on an external non-GPL module I'd point out:
> 1 - Even if we wanted to 'upstream' our code it is very specific
>      and wouldn't really be wanted/accepted.
>      Even if accepted it would always be excluded from builds.
> 2 - It would take man-years to make it meet the kernel code guidelines
>      and to make it portable (from x86).
>      It also contains conditionals because it gets build for windows.
>      I don't like a lot of it.
> 3 - Almost all the calls to kernel functions are through a 'wrapper'
>      file that is compiled on the target system.
>      About the only functions that are directly called are ones like memcpy().
> 4 - It wouldn't be that hard, and would still be GPLv2 if we built
>      two loadable modules, one GPL and one non-GPL and put all our
>      wrapper functions in the GPL one.
>      We'd still need a small wrapper for the non-GPL module, but while
>      Non-GPL modules are supported at all it wouldn't be much work.
> 5 - The continual tweaks for new kernel versions keep us in a job!
>
> Some of the _GPL exports are a PITA:
> - we can't reference count network namespaces (without creating a socket).
> - we can't reference count 'pid' structures making sending signals tricky.
> - I thing the PCIe error handling functions that we ought to be using
>    are GPL.
>
> At the moment we've not needed the fpu :-)
>
> 	David
unfortunatly some does like ZFS which is opensource, but just licensed 
under the wrong copyleft license which cannot be changed that easy.
but its a big loss for the community if such projects get blocked or 
limited by a singe linux developer. but thats just my own oppinion (even 
if not intentionally targeted here of course).
not every project on his planet is a nvidia driver blob. whats most 
important for me is not if its GPL or not. most important is that its 
opensource and copyleft.
so the question is if it isnt possible to create a EXPORT_SYMBOL variant 
which includes acceptable license models, but still restricts 
unacceptable licenses

Sebastian

Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export

[Greg KH]

On Wed, May 08, 2019 at 02:28:21PM +0200, Sebastian Gottschall wrote:
> so the question is if it isnt possible to create a EXPORT_SYMBOL variant
> which includes acceptable license models, but still restricts unacceptable
> licenses

It's not very difficult, "acceptable" license models are all described
in the kernel LICENSES/ directory, and must be GPLv2 compatible.

greg k-h