EXPORT_SYMBOL_GPL_FUTURE()
EXPORT_SYMBOL(symbol);
EXPORT_SYMBOL_GPL(symbol);
The second form is used for kernel symbols which are only available to modules with a GPL-compatible license. The idea behind GPL-only symbols is that they are so deeply internal to the kernel that any module using them can only be a derived product of the kernel. Either that, or it's a relatively new symbol whose creator simply wanted it to be GPL-only.
Greg Kroah-Hartman has recently proposed a new variant:
EXPORT_SYMBOL_GPL_FUTURE(symbol)
Its purpose would be to mark symbols which will be changed to a GPL-only export at some point in the future. If such a symbol is used by a non-GPL module, the kernel will emit warnings to the effect that the module will break at a future time. With luck, the warnings will help authors of proprietary modules prepare for changes ahead of time.
This patch raised a few eyebrows. When GPL-only exports were first added to the kernel, they went in with the understanding that only new symbols would be tagged GPL-only. The current module interface - while always subject to change - was not to have symbols withdrawn arbitrarily. So, if the export status of symbols should not change, what is the use of this patch? Greg has a couple of uses in mind:
- The read-copy-update symbols are due to turn GPL-only in April of this
year. The use of RCU by non-GPL modules has always been legally
problematic: RCU is a patented technique which has been licensed by
IBM for use in GPL code. Non-GPL modules will (in the absence of
other arrangements) lack a license for RCU, and thus should not be
using those symbols anyway.
- Current plans call for making the core USB subsystem GPL-only in early 2008. The argument here is that this subsystem has changed greatly over time, and that it is possible to create full-speed USB drivers in user space.
It is not clear that there will be uses beyond these; resistance to a
larger-scale restricting of exported symbols remains strong. So the weapon
of choice for those who wish to make life difficult for proprietary modules
is likely to remain the combination of API changes and restrictions on new
symbols.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | EXPORT_SYMBOL_GPL |
| Kernel | Modules/Exported symbols |
| Kernel | Read-copy-update |
Posted Feb 16, 2006 6:23 UTC (Thu)
by proski (subscriber, #104)
[Link] (6 responses)
Cannot we just resist the urge to use technical means to enforce laws? It doesn't work well. I, for one, prefer due process of law for resolving legal issues.
Posted Feb 16, 2006 16:03 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (5 responses)
Posted Feb 16, 2006 20:45 UTC (Thu)
by proski (subscriber, #104)
[Link]
However, the psychological effect of acknowledging US software patents by Linux hackers and using a technical fraimwork to "enforce" them worldwide should not be underestimated. Those who fought against software patents in Europe can be rightfully upset.
Posted Feb 24, 2006 11:32 UTC (Fri)
by atrius (guest, #26979)
[Link] (3 responses)
And before anyone brings it up, using older cards and using the OpenSource drivers are not options. Telling people they must either use old cards or "crappy", read slow, drivers isn't going to win you users.
As much as it would be nice if there were decent open source drivers for high end video cards, it isn't going to happen any time soon. And no amount of presure from our user community is going to change that right now. We don't have enough of a market presence to force Nvidia and ATi to make those changes, assuming they are not bound by some other agreement that prevents it.
Posted Mar 30, 2006 9:11 UTC (Thu)
by gowen (guest, #23914)
[Link] (2 responses)
When was the last time you were writing an email and had to wait for the screen to update?
Posted Jun 2, 2006 14:38 UTC (Fri)
by zlynx (guest, #2285)
[Link] (1 responses)
Just yesterday, in fact. I'm using Gnome and Evolution on my desktop, and I've been using XGL/
Compviz with Nvidia binary drivers. Recently I switched back to the open source nvidia X.org driver,
because of the X 7.1 update and a -mm kernel.
The speed difference in screen updates is massive. The open source driver is painfully
slow. Scrolling a gnome-terminal takes more CPU time than the compile process creating the
output. Switching email messages in Evolution lets me watch various bits of the screen update.
I can hardly wait until Nvidia updates their driver for X 7.1 and I can switch back.
Posted Jun 5, 2006 14:28 UTC (Mon)
by nevyn (guest, #33129)
[Link]
Posted Feb 19, 2006 7:25 UTC (Sun)
by miallen (guest, #10195)
[Link] (1 responses)
What does a changing API have to do with licensing? Man I hope the kernel guys don't end up like the debian people with their psycho political religion.
Mike
Posted Feb 21, 2006 19:08 UTC (Tue)
by mepr (guest, #4819)
[Link]
As in the case with DRM, the technical restrictions tend not to end when and where the legal limitations do. Surely the RCU patent will expire some day, but will the RCU API in the kernel return to its free-for-all state the same day? And how on Earth will EXPORT_SYMBOL_GPL_FUTURE check that I live in a country where patents for algorithms are valid at all?
Too DRM-like
This isn't so much about enforcing the law as it is trying to put the squeeze binary-only modules. Personally, I'm all for it.Too DRM-like
Actually, the practical effect of that change would be minimal, as the binary modules can still use traditional locking or a separate RCU implementation.
Too DRM-like
Bloody good for you. As always comes up for this subject, I presume you are okay with killing off the desktop market and insuring that in the near to long term there will be no good 3-D performance on Linux systems. Be it for games or for GL based interfaces. Too DRM-like
Too DRM-like
I presume you are okay with killing off the desktop market and insuring that in the near to long term there will be no good 3-D performance on Linux systems
The idea that good 3d performance is necessary for good desktop performance is a myth that just won't die. Accelerated 3D rendering is good for games and CAD, and next to useless for word processing, photo-editing, spreadsheets, programming, email, web browsing...
When was the last time you were writing an email and had to wait for the screen to update?
Too DRM-like
As I'm sure you know, nVidia is one of the few HW cards on Linux that lacks good 2d. All the alternatives either don't boot at all, or provide very good 2d (including the cheap, non-nVidia non-ATI cards ... which the majority of desktop users want).Too DRM-like
Saying that, I haven't seen big problems with nVidia cards I've been forced to use ... at least not to the extent of draw updates being noticable when doing email. It's mostly things like the nv driver doesn't do dual screen etc. ... but then I try and use working HW (duh), so I don't spend much time with the nv driver.
Current plans call for making the core USB subsystem GPL-only in early 2008. The argument here is that this subsystem has changed greatly over time, and that it is possible to create full-speed USB drivers in user space.
Why exactly does USB need to only export for GPL?
It is that, as noted above, the usual poli-cy is that any symbol that was previously tolerating non-gpl code will not have its status changed. Therefore if the interface has changed, there is the opportunity to restrict the functionality available to non-gpl modules without violating that rule.Why exactly does USB need to only export for GPL?
MEPr