On Mon, Apr 24, 2017 at 10:02:18AM -0400, Paul Gortmaker wrote: > [intel_turbo_max_3 non-modularity] On 24/04/2017 (Mon 11:31) Jean Delvare wrote: > > > Hi all, > > > > I see that the intel_turbo_max_3 driver was originally supposed to be > > modular, and then support for that possibility was removed. Is there > > any fundamental reason why this driver can't be built as a module? Thanks for asking the question Jean, +Srinivas +Peterz > > Re-reading the thread, it was stated that the driver needed exports of > some scheduler functions that weren't currently exported. To me, that > means one of two things -- the driver is poking at scheduler internals > that it shouldn't be and needs to be modified accordingly, or that > someone needs to convince the sched folks that there is valid use cases > for exports of these functions, and _then_ enable modularity. > > I didn't try to build it as a module, so I can't say what the sched > dependencies were, or if they looked valid. But I have seen the sched Reverting Paul's non-module patch and adding "tristate" "default m", it builds cleanly, but fails modpost: ERROR: "sched_set_itmt_core_prio" [drivers/platform/x86/intel_turbo_max_3.ko] undefined! ERROR: "sched_set_itmt_support" [drivers/platform/x86/intel_turbo_max_3.ko] undefined! Peter, Google is failing me for a statement from you on EXPORT_SYMBOL'ing sched_ functions, so can you weigh in here? Have you and Srinivas already discussed this and determined it was unacceptable to export the two sched itmt related functions above? Thanks, > folks being not impressed at how certain arch specific PM/freq stuff has > been implemented in the past, which is why I mention it as a possibility. > > P. > -- > > > > > I am asking because the description of the driver says: > > > > "This driver is only required when the system is not using Hardware > > P-States (HWP). In HWP mode, priority can be read from ACPI tables." > > > > This pretty much implies that this driver will be useless on a wide > > range (maybe even the majority?) of systems. Given this, not being > > forced to build the driver into the kernel would seem preferable. > > > > Thanks, -- Jean Delvare SUSE L3 Support > -- Darren Hart VMware Open Source Technology Center
