kernel/rcupdate.c: make the exports EXPORT_SYMBOL_GPL
PATCH 1/1 kernel/rcupdate.c: make the exports EXPORT_SYMBOL_GPL
Due to the patent situation at least in the USA, the exports of kernel/rcupdate.c should be EXPORT_SYMBOL_GPL.
---
This patch was already sent on:
- 3 Mar 2005
kernel/rcupdate.c renamed from kernel/rcupdate.c.old +3 -3
@@ -506,6 +506,6 @@ }module_param (maxbatch, int,0 ); -EXPORT_SYMBOL (call_rcu); -EXPORT_SYMBOL (call_rcu_bh); -EXPORT_SYMBOL (synchronize_kernel); +EXPORT_SYMBOL_GPL (call_rcu); +EXPORT_SYMBOL_GPL (call_rcu_bh); +EXPORT_SYMBOL_GPL (synchronize_kernel);
Quoted 2 lines · Adrian Bunk
Due to the patent situation at least in the USA, the exports of
kernel/rcupdate.cshould beEXPORT_SYMBOL_GPL.
Based on -what- line of reasoning??? The obvious ones do not apply to this situation.
These need to be put back. Moving them to GPL -- but in a measured manner, as I proposed on this list some months ago -- is fine. Changing these particular exports precipitously is most definitely -not- fine. Here is my earlier proposal:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110520930301813&w=2
See below for a patch that puts the exports back, along with an updated version of my earlier patch that starts the process of moving them to GPL. I will also be following this message with RFC patches that introduce two (EXPORT_SYMBOL_GPL) interfaces to replace synchronize_kernel(), which then becomes deprecated.
Andrew, please apply.
Thanx, Paul
kernel/rcupdate.c +3 -3
@@ -465,6 +465,6 @@ void synchronize_kernel(void) }module_param (maxbatch, int,0 ); -EXPORT_SYMBOL_GPL (call_rcu); -EXPORT_SYMBOL_GPL (call_rcu_bh); -EXPORT_SYMBOL_GPL (synchronize_kernel); +EXPORT_SYMBOL (call_rcu);/* WARNING: GPL-only in April 2006. */ +EXPORT_SYMBOL (call_rcu_bh);/* WARNING: GPL-only in April 2006. */ +EXPORT_SYMBOL (synchronize_kernel);/* WARNING: GPL-only in April 2006. */
Documentation/feature-removal-schedule.txt +13 -0
@@ -15,3 +15,16 @@ Why: It has been unmaintained for a numb against the LSB, and can be replaced by using udev. Who: Greg Kroah-Hartman <[email protected]> +What: RCU API moves to EXPORT_SYMBOL_GPL +When: April 2006 +Files: include/linux/rcupdate.h, kernel/rcupdate.c +Why: Outside of Linux, the only implementations of anything even + vaguely resembling RCU that I am aware of are in DYNIX/ptx, + VM/XA, Tornado, and K42. I do not expect anyone to port binary + drivers or kernel modules from any of these, since the first two + are owned by IBM and the last two are open-source research OSes. + So these will move to GPL after a grace period to allow + people, who might be using implementations that I am not aware + of, to adjust to this upcoming change. +Who: Paul E. McKenney <[email protected]> +
Quoted 4 lines · Paul E. McKenney
These need to be put back. Moving them to GPL -- but in a measured manner, as I proposed on this list some months ago -- is fine. Changing these particular exports precipitously is most definitely -not- fine. Here is my earlier proposal:
ok so there is no disagreement that these should become _GPL eventually, only about the "when". There is agreement also about the expectation that currently no binary module is using these. Personally I would then suggest removing them right now (as is done in -bk); the longer you wait the higher the chance of anyone out there starting to use them and giving/having a problem a year from now, while the current "damage" is expected to be zero.
Quoted 9 lines · Arjan van de Ven
Quoted 4 lines · Paul E. McKenney
These need to be put back. Moving them to GPL -- but in a measured manner, as I proposed on this list some months ago -- is fine. Changing these particular exports precipitously is most definitely -not- fine. Here is my earlier proposal:
ok so there is no disagreement that these should become
_GPLeventually, only about the "when".
Agreed. I would indeed look pretty silly arguing that they should -never- go _GPL, since I proposed moving in that direction some months ago. ;-)
Quoted 2 lines
There is agreement also about the expectation
that currently no binary module is using these.
Agreed, in that I know of no binary module that uses RCU. However, I cannot -prove- that there is no such module.
Quoted 5 lines
Personally I would then
suggest removing them right now (as is done in -bk); the longer you wait the higher the chance of anyone out there starting to use them and giving/having a problem a year from now, while the current "damage" is expected to be zero.
If someone starts using the exports in a binary module given the warnings ("/* WARNING: GPL-only in April 2006. */"), they have done so with the knowledge that they will need to change. Therefore, any future "damage" would be self-inflicted. Even if they failed to notice the warnings, IBM would have made a reasonable and conscientious effort to inform them. In contrast, if the exports change suddenly now, then the (unlikely, but still possible) "damage" could be argued to be inflicted, indirectly, by IBM. I would (and do) vehemently disagree with such an argument, but my opinion might not count for much. IANAL, after all.
And of course, these exports are a special case due to the well-known presence of the RCU patents.
This line of reasoning might seem a bit strange (it certainly did to me at first!), but I eventually had to admit that it is quite a bit less strange than some things that have actually happened over the past few years. :-/
Finally, please note that this is not a "Mr. Binary-Module, you have a year to complain and maybe change my mind" type of notification. This is instead a "this change -will- happen, but I am doing you the courtesy of giving you advance notice of an upcoming change in an implicit patent license" type of notification. From the patch:
+ So these will move to GPL after a grace period to allow + people, who might be using implementations that I am not aware + of, to adjust to this upcoming change.
Fair enough?
Thanx, Paul