Re: intel_turbo_max_3 non-modularity

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

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