Re: intel_turbo_max_3 non-modularity

[Darren Hart <dvhart@infradead.org>]

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