Re: So, what's the status on the recent patches here?

Eugeny S. Mints
2006-08-29T21:46:25Z

2006/8/29, Pavel Machek <pavel@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@gmail.com>:
> > > On 8/19/06, Dave Jones <davej@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
>