Re: [Xen-devel] [PATCH v3 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

["Wang, Wei W" <wei.w.wang@xxxxxxxxx>]

On 17/06/2015 15:54, Jan Beulich wrote:
> >>> On 16.06.15 at 09:09, <wei.w.wang@xxxxxxxxx> wrote:
> > On 15/06/2015 20:37, Jan Beulich wrote:
> >> >>> On 15.06.15 at 14:28, <wei.w.wang@xxxxxxxxx> wrote:
> >> > On 15/06/2015 17:15, Jan Beulich wrote:
> >> >> >>> On 15.06.15 at 02:30, <wei.w.wang@xxxxxxxxx> wrote:
> >> >> > We actually want it be intel_pstate specific. If maintainers
> >> >> > agree, I think renaming it to intel_pstate_policy is a good option.
> >> >>
> >> >> No, this name is just ugly. If you need driver specific data, have
> >> >> a void
> >> > pointer
> >> >> in the generic structure; the driver can then allocate memory to
> >> >> be pointed to by that, and can store there whatever private data it
> needs.
> >> >
> >> > OK. I plan to make the following changes:
> >> >
> >> > 1) in cpufreq_policy, add a field - void *private_data;
> >> >
> >> >
> >> > 2) add a new structure:
> >> >  struct intel_pstate_policy {
> >> >  unsigned int policy;
> >> > }
> >>
> >> struct intel_pstate_private or struct intel_pstate_data please.
> >>
> >
> > "struct perf_limits" is currently used only by intel_pstate, should we
> > also move it to the intel_pstate_private struct, instead of the
> cpufreq_policy?
> 
> Yes of course - anything private to the driver should go there.

Just realized that " struct perf_limits " will also need to be used in the 
common code (e.g. set max_perf_pct in pmstat.c), so I plan to keep it in the 
cpufreq_policy struct. Please let me know if you have a different opinion. 

Best,
Wei 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel