On 09/09/2015 19:57, Jan Beulich wrote: >>> On 09.09.15 at 12:35, <wei.w.w...@intel.com> wrote: > On 09/09/2015 18:10, Jan Beulich wrote: >>>> On 09.09.15 at 11:35, <wei.w.w...@intel.com> wrote: >>> Using the drinking vessel analogy, we are not putting milk and water >>>into the vessel at the same time. If the producer puts water into the >>>vessel, then the consumer simply consumes water; If the producer puts >>>milk into the vessel, then the consumer simply consumes milk. I think >>>we don't need to worry about what type of drinking is put inside the >>>vessel, because the vessel is just an intermediate place holding the >>>liquid between the producer and consumer - the consumer has the >>>privity of contract with the producer and it has the right logic to >>>deal > with what's inside the vessel. > >> This analogy breaks for a blind: How would he know whether there's >> water or > milk in there? He'd have to try it. >>Now what if we use >venom instead of milk in your analogy? > >>Bottom line - the consumer needs to know what kind of data it is to >>expect to > consume. > > There is a contract between the consumer and the producer. In our > case, the contract is "p_cpufreq->scaling_driver". Before the right > consumer consumes the value of " uint32_t scaling_max_perf ", it goes through > the check: > + if (!strncmp(p_cpufreq->scaling_driver, > + "intel_pstate", CPUFREQ_NAME_LEN) ) > , where "intel_pstate" can be changed to other new driver names > (contract) in the future.
> Which is precisely what I already said doesn't scale. Can you please explain more why it doesn't scale? >From my point of view, any other future value representation can be passed >from the producer to the related consumer through this method. Best, Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
