On Mon, Aug 14, 2006 at 06:00:20PM -0700, Greg Kroah-Hartman wrote: > > This adds a whole bunch of new code, and doesn't seem to make any > > existing code any simpler (to me at least). From a cpufreq point of view, > > what does adding this buy us? What problem do we have today that is > > being solved by all this? > > > > Every explanation of powerop I've seen so far dives into microdetails, > > whilst the 10,000ft view has always passed me by other than "this is > > what we've had in the embedded world". > > > > The diagram at http://lists.osdl.org/pipermail/linux-pm/2006-August/003196.html > > also confuses me. I was under the impression that powerop was adding additional > > userspace interfaces. If we're not changing how things from a userspace > > point of view, we're churning a lot of kernel code,.. why? > > > > Clue me in here, I'm feeling thick. > > You're not alone, I really don't get it either. > > But I guess we'll just wait for the next round of unified patches and > then go from there. I have concerns over this because the cpufreq code has gotten pretty damned complicated in parts, and it's really impacting our ability to fix bugs in the thing. Every time something new falls out we have to play archaeologist looking up a lot of ancient changes to figure why we did x in y way, and why z didn't work, and it's getting quite unfun. In a lot of cases even the original authors of the problematic parts can't remember their reasoning. I've got a fairly good handle on most parts, but things like the recent cpufreq vs hotplug-cpu fiasco (which went in via some other route rather than the cpufreq tree) really threw me a curve-ball, and no-one other than Linus, Andrew and myself stepped up to the plate to fix that mess, despite there being the better part of a half dozen people who had hacked on it during its integration. Dave -- http://www.codemonkey.org.uk
