Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

["Eugeny S. Mints" <eugeny.mints@gmail.com>]

Matthew Locke wrote:
> On Sep 14, 2006, at 2:12 AM, Pavel Machek wrote:
> 
>> Hi!
>>
>>>>> Date: Mon, 11 Sep 2006 21:36:37 +0200
>>>>> From: Pavel Machek <pavel@ucw.cz>
>>>>>
>>>>> Kernel interface is not something to be experimented with.
>>>> Disagree.  How else to get it right??
>>>> Try, learn, improve.  That's experimentation.
>>>> Linux has no "stable API nonsense" ...
>>>>
>>>> The point of "cathedral vs. bazaar" was that experimentation
>>>> and evolution are more successful processes than "get it
>>>> right the first time".
>>> ---
>>>
>>> I think Pavel's point was that the userspace interface to
>>> the kernel (at least the syscall interface) is stable (open to
>>> Extension by addition of syscalls, but closed to modification
>>> or deletion of existing and that any experimentation needs to
>>> happen before functionality goes into the mainstream.
>> Yes, that was my point. (And I'd add "plus you can't get around that
>> by introducing interface hidden by #ifdef").
>>
>>> That said, I do think we probably need to add a new interface to
>>> cover operating points, because some of believe that policy needs
>>> to be in user space and the whole point of the OP abstraction is
>>> that operating points are atomic. You can't just add knobs to
>>> control more factors, because all those knobs need to be turned
>>> at the same time. Setting an operating point is inherently an
>>> atomic operation, not n separate operations that can be taken
>>> serially.
>> Ok, "needs to be atomic" is first real argument for OP abstraction. I
>> wonder if we can get around that by delaying the transaction until
>> userspace tells us it made all the changes... otoh that is going to be
>> messy.
>>
>> But do you have some reasonable way to integrate OP with cpufreq?
> 
> Yes, it was presented in the PowerOP/cpufreq integration patches.  The 
> cpufreq_driver layer is the natural integration point.
Exactly.

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.

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

Paval, plz NOTE, that  you don't have lkml in CC on this thread and I personally 
feel that you've brought a really terrible confusion to everyone with your lkml 
step. I'm wondering whether you are braking "no cross postings" rule as well.....

Eugeny
> 
>> 								Pavel
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>> _______________________________________________
>> linux-pm mailing list
>> linux-pm@lists.osdl.org
>> https://lists.osdl.org/mailman/listinfo/linux-pm
>>
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>