From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?] Date: Thu, 14 Sep 2006 11:12:11 +0200 Message-ID: <20060914091211.GA14874@elf.ucw.cz> References: <20060913045405.BA7DD1A0084@adsl-69-226-248-13.dsl.pltn13.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: Preece Scott-PREECE Cc: linux-pm@lists.osdl.org List-Id: linux-pm@vger.kernel.org Hi! > > > Date: Mon, 11 Sep 2006 21:36:37 +0200 > > > From: Pavel Machek > > > > > > 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/blo= g.html