Vitaly, Vitaly Wool wrote: > Eugeny, > > On 9/14/06, Eugeny S. Mints <eugeny.mints at gmail.com> wrote: > >> Separate or one universal user space<->kernel interface is another story. >> Universal is preferred of course and in two words to achieve universal >> interface >> current cpufreq interface needs to be improved - but remains unchanged >> for user >> space !!!! - in the way to handle "chose closet predefined frequency >> to an >> arbitrary freq value echo'ed into /sys/cpufreq/cpuN/freq" >> functionality in user >> space instead of in the kernel. Assuming that frequency attribute is >> exported >> for all available operating points it is possible to implement the >> "cpufreq >> frequency selection logic" in user space and having such functionality >> in the >> kernel just violates the main rule of having everything possible >> outside of the >> kernel. > > Let's not be in a hurry, if possible. > I wonder why not to present PowerOP with a _separate_ *kernel* API at > the moment. it is exactly how PowerOP submission is positioned - it was submitted as a standalone patch without any relationship to cpufreq integration patch. Cpufreq patch was submitted mostly for reference and discussion; to demonstrate that future integration with cpufreq is in mind and outline that PowerOP will not require cpufreq _interface_ to be changed. > >> More details here: >> http://lists.osdl.org/pipermail/linux-pm/2006-September/003660.html >> and here >> http://lists.osdl.org/pipermail/linux-pm/2006-September/003671.html > > Again, let's first make PowerOP accepted in mainline and then start > talking about integration with cpufreq. that's exactly our understanding of an evolutionary development process. > Looking again at the links you've provided, I'd guess BTW that you > meant configfs not sysfs in some cases. configfs is in my TODO list. Eugeny > > Vitaly >
