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;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'Jiri Kosina' <jikos@kernel.org>,
        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" <x86@kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end()
 export
Thread-Topic: [PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end()
 export
Thread-Index: AQHVAkq0vUiV5g3MjEetDYjdoqqHvaZfXF+Q
Date:   Tue, 7 May 2019 10:31:28 +0000
Message-ID: <957b01f742ed47d1ac9e0ea1277d155b@AcuMS.aculab.com>
References: <761345df6285930339aced868ebf8ec459091383.1556807897.git.luto@kernel.org>
 <20190502154043.gfv4iplcvzjz3mc6@linutronix.de>
 <nycvar.YFH.7.76.1905032044250.10635@cbobk.fhfr.pm>
 <nycvar.YFH.7.76.1905040849370.17054@cbobk.fhfr.pm>
In-Reply-To: <nycvar.YFH.7.76.1905040849370.17054@cbobk.fhfr.pm>
Accept-Language: en-GB, en-US
Content-Language: en-US
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

...
> 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)