2006/8/29, Pavel Machek <pavel at suse.cz>: > Hi! > > Okay, I never liked opPoint framework... so your critism seems okay, > but do your patches really solve all the points you raised? it's hard to catch up in this way until people start to comment out the [patches] code. I haven;t seen any comments on my code except those Greg made. I'm working to address Greg's comments. > > On Sun 2006-08-27 13:54:31, Eugeny S. Mints wrote: > > 2006/8/26, David Singleton <daviado at gmail.com>: > > > On 8/19/06, Dave Jones <davej at redhat.com> wrote: > > > > On Sat, Aug 19, 2006 at 08:20:45PM -0700, David Singleton wrote: > ... > > > 1) I believe I now have the right kernel interface for a common > > > power management infrastructure. > > > - md_data has an issue from OO design paradigm perspective. OpPoint > > requires an entity above PowerOP to know internals of arch md_data (see > > centrino-dynamic-powerop.c implementation) and thus requires an arch > > Is that what you were trying to solve with string parsing? Exactly. The parsing is result of PowerOP patches evolution from exporting 'struct powerop_point' through 'void *' upto string parsing. 'void *' approach would be fine if we agreed to have all instances manipulating on points via sysfs/configfs interface. But the requirement on inkernel operating points registration modules which came from the discussions on the list still persists. For example cpufreq needs such inkernel registration module. String parsing comes to the scene to register power parameters without inclusion of an arch header file. OpPoint has not such header file included in the registration module x86 code just because OpPoint has wrong definition of operating point with some unknown frequency and voltage fields in 'struct oppoint' while the fields must be defined in arch dependent part of the code. I'm still pondering about approach to have parsing only in powerop core layer according to your comments, btw. Eugeny > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >
