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

[David Laight <David.Laight@ACULAB.COM>]

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