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

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

On 10/09/2015 17:55,  Jan Beulich wrote:
>>> On 10.09.15 at 11:33, <wei.w.wang@xxxxxxxxx> wrote:
> On 09/09/2015 16:17,  Jan Beulich wrote:
>>>> On 10.09.15 at 07:35, <wei.w.wang@xxxxxxxxx> wrote:
>> Seems we still cannot get rid of these strncmp()s. Is this 
>> acceptable, or should we change "struct cpufreq_driver" to use enum 
>> represented driver name as well, or do you have a better suggestion?
> 
>> The one I explained before: Express the data representation type in 
>> an enum,
> not the driver kind. But even if we went with the
>> above, the strcmp() ugliness would at least be limited to the 
>> producer, not
> enforced onto any number of consumers.
> 
> No.  I think in our previous discussion, there is no problem with "the 
> data representation type", any future data representation, as long as 
> it is in "uint32_t", it can use "uint32_t scaling_max_perf" to hold 
> that value representation.

> Okay, "representation" was a badly chose term. "Meaning of the data"
> would have been better.

> Your concern was that the following doesn't scale well.
> 
> +    if (!strncmp(p_cpufreq->scaling_driver,
> +                  "intel_pstate", CPUFREQ_NAME_LEN) )
> 
> So we are trying to change the driver name thing to be in enum. 

> No, that was never what I've been asking for. I've always said that the 
> consumer of the data ought to have a way to know what 
> kind of data it is dealing with. I.e. the enum ought to represent what 
> meaning the data has (frequency vs percentage).

Ok. If we add this "enum meaning_of_data", the xen_get_cpufreq_para will exceed 
128Byte, which cannot even pass the compilation. I am not sure how to deal with 
this nicely. Do you have a suggestion? 

Best,
Wei

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