On Mon, Sep 04, 2006 at 11:06:45AM +0200, Pavel Machek wrote: > On Sun 2006-09-03 17:40:27, Scott E. Preece wrote: > > > > | From: Pavel Machek<pavel at ucw.cz> > > | > > | On Sun 2006-09-03 17:12:22, Scott E. Preece wrote: > > | > | From: Pavel Machek<pavel at ucw.cz> > > > | > Not speaking to either of the current code submissions, I would say that > > | > having a kernel interface for defining OPs and a kernel interface for > > | > setting the OP, was a reasonably clean interface. > > | > > | Well, me and Rafael disagree, and you do not really listen to > > | arguments. Now you can either fix the interface, or try to submit code > > | to lkml despite our NAKs. Go ahead and prepare for some flaming... > > --- > > > > I think I'm listening to arguments just as much as you guys are! We just > > disagree. What are your criteria for "a clean interface"? Why do you > > think that n separate set-parameter() interfaces, with no consistency > > relationship between them, are cleaner than one define-op() and one > > set-op() interface? > > Because we already have cpufreq-set-parameter() interface and > enter-suspend-state() interface. We can't really get rid of them. > This is true. Yet todays cpufreq interface is not up to the job of providing power management for many embedded platforms. > If you add set-op() replacing both cpufreq-set-parameter() and > enter-suspend-state(), we'll end up with two different interfaces for > each interface; that's considered "mess". Why can't they coexist? Are you arguing that the cpufreq interface be morphed to support power op applications? --mgross > 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 at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm
