EXPORT_SYMBOL_GPL_FUTURE() [LWN.net]

The kernel has a couple of macros for making internal symbols available to loadable modules:

    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.

(Log in to post comments)

Too DRM-like

Posted Feb 16, 2006 16:03 UTC (Thu) by bronson (subscriber, #4806) [Link]

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

Posted Feb 16, 2006 20:45 UTC (Thu) by proski (subscriber, #104) [Link]

Actually, the practical effect of that change would be minimal, as the binary modules can still use traditional locking or a separate RCU implementation.

However, the psychological effect of acknowledging US software patents by Linux hackers and using a technical framework to "enforce" them worldwide should not be underestimated. Those who fought against software patents in Europe can be rightfully upset.

Too DRM-like

Posted Feb 24, 2006 11:32 UTC (Fri) by atrius (guest, #26979) [Link]

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.

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.

Too DRM-like

Posted Mar 30, 2006 9:11 UTC (Thu) by gowen (guest, #23914) [Link]

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

Posted Jun 2, 2006 14:38 UTC (Fri) by zlynx (subscriber, #2285) [Link]

When was the last time you were writing an email and had to wait for the screen to update?

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.

Too DRM-like

Posted Jun 5, 2006 14:28 UTC (Mon) by nevyn (subscriber, #33129) [Link]

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