>>> On 10.09.15 at 11:33, <wei.w.w...@intel.com> wrote: > On 09/09/2015 16:17, Jan Beulich wrote: >>>> On 10.09.15 at 07:35, <wei.w.w...@intel.com> 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). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
