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