| Message ID | 50DE1A74.4040607@lwfinger.net (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Friday, December 28, 2012 04:17:24 PM Larry Finger wrote: > Since commit 2aacdff entitled "cpufreq: Move common part from governors to > separate file", whenever the drivers that depend on this new file > (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module > named cpufreq_governor is created. It seems that kmake is smart enough to create > a separate module whenever more than one module includes the same object file. > As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the > resulting module has no license specified, which results in logging of a "module > license 'unspecified' taints kernel". In addition, a number of globals are > exported GPL only, and are therefore not available. > > Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> > --- > > This particular patch is the simplest possible; however, it hides the intent. I > have prepared the longer version that makes the reason clearer by adding a new > configuration variable that is dependent on the other two, and rearranges > drivers/cpufreq/Makefile. That version could be submitted if that is what is > desired. Yes, please. > The changes to cpufreq_governor.c are the same as in this version. I wonder if that's avoidable? The intention is not to create an additional module, clearly. Thanks, Rafael
On 12/28/2012 05:01 PM, Rafael J. Wysocki wrote: > On Friday, December 28, 2012 04:17:24 PM Larry Finger wrote: >> Since commit 2aacdff entitled "cpufreq: Move common part from governors to >> separate file", whenever the drivers that depend on this new file >> (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module >> named cpufreq_governor is created. It seems that kmake is smart enough to create >> a separate module whenever more than one module includes the same object file. >> As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the >> resulting module has no license specified, which results in logging of a "module >> license 'unspecified' taints kernel". In addition, a number of globals are >> exported GPL only, and are therefore not available. >> >> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> >> --- >> >> This particular patch is the simplest possible; however, it hides the intent. I >> have prepared the longer version that makes the reason clearer by adding a new >> configuration variable that is dependent on the other two, and rearranges >> drivers/cpufreq/Makefile. That version could be submitted if that is what is >> desired. > > Yes, please. I'll send it shortly. >> The changes to cpufreq_governor.c are the same as in this version. > > I wonder if that's avoidable? The intention is not to create an additional > module, clearly. It appears not to be possible. I don't know enough about to kmake to understand why it is forcing a new module. Perhaps some expert knows what Kconfig or Makefile magic will prevent that. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 28, 2012 at 05:45:54PM -0600, Larry Finger wrote: > >I wonder if that's avoidable? The intention is not to create an additional > >module, clearly. > > It appears not to be possible. I don't know enough about to kmake to > understand why it is forcing a new module. Perhaps some expert knows > what Kconfig or Makefile magic will prevent that. kbuild is building an additional module just because the makefile is adding the new objects in the obj-m list directly, as in: obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand.o cpufreq_governor.o obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o cpufreq_governor.o To build just two modules the Makefile would have to be modified [1] into something into something like: obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand_mod.o cpufreq_ondemand_mod-y := cpufreq_ondemand.o cpufreq_governor.o obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative_mod.o cpufreq_conservative_mod-y := cpufreq_conservative.o cpufreq_governor.o so that only two .o are added to obj-m, but that's not correct either as you end up with cpufreq_governor symbols exported twice. I think the only way would be to force cpufreq_governor as builtin with an automatic Kconfig option. Fabio 1. http://lxr.linux.no/#linux+v3.7.1/Documentation/kbuild/makefiles.txt#L191
On 12/28/2012 06:33 PM, Fabio Baltieri wrote: > On Fri, Dec 28, 2012 at 05:45:54PM -0600, Larry Finger wrote: >>> I wonder if that's avoidable? The intention is not to create an additional >>> module, clearly. >> >> It appears not to be possible. I don't know enough about to kmake to >> understand why it is forcing a new module. Perhaps some expert knows >> what Kconfig or Makefile magic will prevent that. > > kbuild is building an additional module just because the makefile is > adding the new objects in the obj-m list directly, as in: > > obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand.o cpufreq_governor.o > obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative.o cpufreq_governor.o > > To build just two modules the Makefile would have to be modified [1] > into something into something like: > > obj-$(CONFIG_CPU_FREQ_GOV_ONDEMAND) += cpufreq_ondemand_mod.o > cpufreq_ondemand_mod-y := cpufreq_ondemand.o cpufreq_governor.o > obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) += cpufreq_conservative_mod.o > cpufreq_conservative_mod-y := cpufreq_conservative.o cpufreq_governor.o > > so that only two .o are added to obj-m, but that's not correct either as > you end up with cpufreq_governor symbols exported twice. > > I think the only way would be to force cpufreq_governor as builtin with > an automatic Kconfig option. > > Fabio > > 1. http://lxr.linux.no/#linux+v3.7.1/Documentation/kbuild/makefiles.txt#L191 Fabio, Thanks for the explanation. Now I think I know how to do it. V3 follows. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: wireless-testing-new/drivers/cpufreq/cpufreq_governor.c =================================================================== --- wireless-testing-new.orig/drivers/cpufreq/cpufreq_governor.c +++ wireless-testing-new/drivers/cpufreq/cpufreq_governor.c @@ -25,6 +25,7 @@ #include <linux/tick.h> #include <linux/types.h> #include <linux/workqueue.h> +#include <linux/module.h> #include "cpufreq_governor.h" @@ -316,3 +317,7 @@ second_time: return 0; } EXPORT_SYMBOL_GPL(cpufreq_governor_dbs); +MODULE_AUTHOR("Alexander Clouter <alex@digriz.org.uk>"); +MODULE_DESCRIPTION("'cpufreq_governor' - A mini-module containing " + "common code for cpufreq_conservative and cpufreq_ondemand"); +MODULE_LICENSE("GPL");
Since commit 2aacdff entitled "cpufreq: Move common part from governors to separate file", whenever the drivers that depend on this new file (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module named cpufreq_governor is created. It seems that kmake is smart enough to create a separate module whenever more than one module includes the same object file. As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the resulting module has no license specified, which results in logging of a "module license 'unspecified' taints kernel". In addition, a number of globals are exported GPL only, and are therefore not available. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> --- This particular patch is the simplest possible; however, it hides the intent. I have prepared the longer version that makes the reason clearer by adding a new configuration variable that is dependent on the other two, and rearranges drivers/cpufreq/Makefile. That version could be submitted if that is what is desired. The changes to cpufreq_governor.c are the same as in this version. Larry cpufreq_governor.c | 5 +++++ 1 file changed, 5 insertions(+) --- -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html