Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 3 May 2019 20:49:05 +0200 (CEST)
From:   Jiri Kosina <jikos@kernel.org>
To:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
cc:     Andy Lutomirski <luto@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Rik van Riel <riel@surriel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Nicolai Stange <nstange@suse.de>,
        Paolo Bonzini <pbonzini@redhat.com>,
        =?ISO-8859-2?Q?Radim_Kr=E8m=E1=F8?= <rkrcmar@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, x86@kernel.org,
        stable@vger.kernel.org, Jiri Kosina <jikos@jikos.cz>
Subject: Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end()
 export
In-Reply-To: <20190502154043.gfv4iplcvzjz3mc6@linutronix.de>
Message-ID: <nycvar.YFH.7.76.1905032044250.10635@cbobk.fhfr.pm>
References: <761345df6285930339aced868ebf8ec459091383.1556807897.git.luto@kernel.org> <20190502154043.gfv4iplcvzjz3mc6@linutronix.de>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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