[ohm] OHM vs. PPM
rob.taylor at codethink.co.uk
Mon May 5 10:19:09 PDT 2008
Holger Macht wrote:
> On Mi 30. Apr - 16:51:56, Rob Taylor wrote:
>> Holger Macht wrote:
>> Hi Holger, sorry for taking so long to reply.
>>> might be a quite provoking subject, however, I like to attract some
>>> responses... ;-)
>>> For quite some while now, I'm looking into finding a replacement (and
>>> starting to become active in the development for it), for the powersave
>>> daemon we use on openSUSE based distributions. Actually it's about the
>>> question: "Who does the power management job when there's no desktop
>>> Obviously, two frameworks caught my eye... open-hardware-manager (OHM )
>>> and the power-policy-manager (PPM ). So I have a couple of questions:
>>> 1. Is OHM aught to be used on usual desktop/laptop systems? I mean, it
>>> would be a valid target to define that OHM is "just" meant for
>>> embedded devices and thus, development wouldn't consider
>>> problems/drawbacks on the desktop side.
>> OHM needs some work before its usable on a desktop system, mainly in that
>> it should become a session daemon rather than a system daemon - connecting
>> up to X from the system is not ideal.
> Definitely agree here. We did this in the past and it kinda worked, but we
> always had to do ugly hacky solutions.
> But it depends on if you actually want OHM to run in desktop session.
> We've already solved the issues for defining policy in the desktop
> session. We've got desktop policy managers like kpowersave and
> gnome-power-manager for that. What I like to solve is not the desktop
> policy part, but the server and system level bits.
> This might sound strange, using an architecture created for embedded
> devices, for servers. But those two systems have more in common than one
> might think of. For embedded, at least AFAIK, you can consider the one
> session you have as system session. There's nothing like a decent desktop
> session. For server systems without a desktop, you also have only this one
> system level.
>>> 2. Are you guys in contact in any kind with the PPM Intel developers?
>> Not particularly. I've tried to get a discussion going, but haven't had
>> much luck. It maybe that I've just not managed to reach the right people.
> Yes, this obviously is sometimes kinda hard.
>>> 3. As I understand it, OHM is more than PPM. It doesn't exclusively look
>>> at power management, but also on other aspects. Due to it's plugin
>>> system, it could be used for any kind of things. Same plugin system in
>>> PPM, but with the difference that PPM's defined target is just power
>>> management AFAICT. So, at first glance, there are duplicate
>>> development efforts. Again ;-) I mean, we had so many different
>>> implementations (scripts, C++ daemons, etc..) in the past, so I think
>>> it's time to agree on one single framework. At least I have to choose
>>> one :-) Any statement about that?
>> Yep, OHM is more about generic policy management and allowing an easy way
>> to define behaviour. I'd hoped that starting a fd.o project might encourage
>> people to come in and discuss the various viewpoints, but that's not
>> happened hugely. I should note that OHM was started before PPM became
> I know that. PPM was definitely developed more secret that OHM.
>> I guess the main difference between OHM and PPM at this point is that PPM
>> is much more structured, with a langauge for policy definition. OHM at this
>> point is really little more than a key/value state store, an event
>> transition system and plugins that can respond to events and modify the
>> I talked to David Zeuthen about both frameworks a while back at the GNOME
>> Boston summit, his take was that both were wrong for running at the system
>> level as policy can often be user and desktop specific.
> I don't agree here. In my opinion, OHM shouldn't handle the bits which are
> desktop and/or user specific. Of course it can do, but see below... For
> embedded, you can use any policy plugin you like. You don't have something
> like a desktop session, have you? Or the other way round, you don't have
> something like a system session. You only have one single session AFAIKS.
> For the Laptop case, we have desktop session policy agents. For system
> level, I like to use OHM. You can consider the system session as just
> another session without an X server.
> Let me become a little more detailed about what I'm thinking of:
> In openSUSE, we're currently using the following mechanism. System boots
> up, having the powersaved started at an early point. It defines a default
> power management policy until another, maybe more intelligent, policy
> agent comes up. You can do this nicely with setting priority on a D-Bus
> service. powersaved is setting up a org.freedesktop.PowerManagement
> service with low priority. When gnome-power-manager comes up, it requests
> the same service with higher priority and obtains it. At this point in
> time, the powersaved knows that it shouldn't handle power management (or
> certain tasks) anymore because there is a more intelligent agent, one the
> user can deal with. As soon as gnome-power-manager quits, thus dropping
> the service, powersaved kicks in automatically. This way prevents the
> system from being left alone without a default policy (caring about power
> button presses, etc.), in turn making it appropriate for server use.
> And that's were I like to see OHM. Replacing the system level bits of
> powersaved. Serving two main tasks: The first is to carry out a default
> policy until a more intelligent agent is running (this policy could even
> be read out from a configuration a desktop policy agent once defined). The
> second is to care about policy a common user should never be able to
> see. Things like thermal management or fine-grained power management
I'm going to just jot down my thoughts here on session-v-system. I'm not
particularly thinking about OHM here, but there's some thoughts I want
to make clear :)
Now one thing I need to understand here is: why does doing what
powersaved does require a system service?
Taking things it does from the docs:
* Four predefined powersave schemes
- sounds pretty much like a session/user level decision
* Full support for cpu frequency scaling, either through kernel
(ondemand governor) or within userspace. There are three predefined cpu
- surely this is covered by HAL's org.freedesktop.Hal.Device.CPUFreq
* Battery management. This includes warning the admin/user when a
critical battery state is reached and automatic shut down of the system
on specific events (fully configurable).
- signalling should be done via HAL's battery namespace 
- action policy could be system or user defined.
* Supporting Suspend to disk, Suspend to and ram and standby. This
includes caring about setting up modules, services and a lot more.
- should be covered by
org.freedesktop.Hal.Device.SystemPowerManagement interface 
* Automatic cpu throttling depending on the current cooling policy
- This is interesting. Should be system defined policy for sure.
* Full featured dbus implementation for communication with various
clients like kpowersave, wmpowersave, or gkrellm-powersave.
- obviously unneeded if you don't need a system daemon.
As I see it the two things that have got associated in this discussion
that need disassociating is system and session *policy* and system and
Using PolicyKit we can define what actions a session-level daemon can
perform, so if an administrator wishes to take control of some aspects
of power management (i.e. multi user system) they could:
* have a policy manager running as an administrator with the
administrators system-specific policy, authorized by policykit
* disallow those actions or policy decisions by other users.
One question of session-vs-system is at what point power managment
policy is needed. Is it needed before gdm runs?
What do you guys think?
>>> I already checked out both frameworks and gave them a quick try, both
>>> seemed to work, at least to a certain extend. But "remaining issues" which
>>> can be fixed are not a problem here.
>> How's your investigation gone so far?
> Had a closer look, and OHM seems to be exactly what I was looking for ;-)
> Of course depending on the above opinions and if you agree for what OHM
> should actually be designed for.
> Ohm-devel mailing list
> Ohm-devel at lists.freedesktop.org
More information about the Ohm-devel