On Thu, 2017-04-27 at 14:48 -0700, Darren Hart wrote: > 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: > > [...] > > > > > 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? Before to this patch, only intel_pstate driver called these two sched_xx() functions. intel_pstate can be only be built-in, so no effort was made to export these functions when they were developed to add ITMT support. But turbo_max_3 driver driver will only load on a subset of non HWP Broadwell systems, making module is not a bad idea. To do that we can export these two sched_xx() functions as they are only related to ITMT function anyway. If Peter agrees, I can send a patch to change this. Thanks, Srinivas
