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

[Pavel Machek <pavel@ucw.cz>]

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?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html