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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20190503180739.GF5020@zn.tnic>
Date:   Fri, 3 May 2019 11:54:54 -0700
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        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>,
        =?utf-8?Q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
        stable <stable@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5BD87ACE-1200-4612-AA83-1590DA9E45E5@amacapital.net>
References: <761345df6285930339aced868ebf8ec459091383.1556807897.git.luto@kernel.org> <20190502154043.gfv4iplcvzjz3mc6@linutronix.de> <CALCETrWTCB9xLVdKCODghpeQpJ_3Rz3OwE8FB+5hjYXMYwYPLg@mail.gmail.com> <20190502165520.GC6565@zn.tnic> <bcb6c893-61e6-4b08-5b40-b1b2e24f495b@redhat.com> <20190503180739.GF5020@zn.tnic>
To:     Borislav Petkov <bp@alien8.de>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On May 3, 2019, at 11:07 AM, Borislav Petkov <bp@alien8.de> wrote:
>=20
>> 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).
>=20
> 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.
>=20

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

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

(I actually hope we unexport it once simd_get() and friends land =E2=80=94 t=
hey=E2=80=99re a much better API, and we should migrate over to it.)