On Wed, 25 Jul 2007, Jerome Glisse wrote:Ok, i was just trying to stress that the end result is the same from the user point of
On 7/24/07, david@xxxxxxx <david@xxxxxxx> wrote:will each plugin have it's own interface? or will you have one interface
to access the plugins and then the plugins do things behind the scenes?
I'll bet that the API for the plugins is common, and if so then it could
be similar to the API that I suggested.
I take here ohm as a reference (this come from my limited understanding of
this daemon so there might be inaccuracy) driver export through HAL
there power management tunning capacity, Then an ohm plugin would use
HAL to give a higher
view of this capacity and also manage policy, preference, permission, ...
Last consumer in power management food chain would be an user interface which
will communicate with ohm (and with all ohm plugin) so desktop writter (gnome,
kde, ...) can write some kind of power management center where each ohm plugin
can have its own panel. So in the end the user got one place to do all its
power management which is the goal i think you are trying to aim.
no. I am talking about the interface to the drivers that things like HAL would use
Tell me how i do this in your model:> For instance on graphics card you could do the following (maybe more):
> -change GPU clock
> -change memory clock
> -disable part of engine
> -disable unit
> i truly don't think you can make a common interface for all this, more
> over there might be constraint on how you can change things (GPU &
> memory clock might need to follow a given ratio). So you definitely
> need knowledge in the user space program to handle this.
sure you can, just enumerate all the options the driver writer wants to
offer as options. yes this could be a lengthy list, so what?
My point was that your interface by trying to fit square pegs into round hole
will fail to expose all subtility of each device which might in the end bring
to wrong power management decision. So i believe we can't sum up
power management to list of mode whose attribute are power consumption
& capacity.
it's possible (which is part of the reason I started the thread), but so far there hasn't been anything identified that is a really bad fit.
You have to provide an ohm plug in (in an ohm world) where policy for this device will beAnd there is no way to design an abstraction given that all hw we will have
to deal with are too much different and do not follow any standard things
(beside ACPI there is other way to save power brightness, gpu/memory
clock, pll, ...) so i don't see how one might give a common view of things
which are fundamentally different in how they affect consumption (same end
result with many different paths leading to it).
so you are saying that the power management software must know the details of each and every driver, and if you add a new driver you must change the power management software before it can do anything (including allowing manual control of the modes)
seems to me I heard similar arguments several years ago about the CPU speed settings, it turns out that the cpufreq interface works really well for them and the software that's controlling things no longer needs to know the details of every CPU.cpufreq is unification of processor frequency management, what you try to unify here
why did it work there but can't work anywhere else?
David Lang