[ohm] OHM vs. PPM

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,
>> 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
>>> applet?"
>>>
>>> Obviously, two frameworks caught my eye... open-hardware-manager (OHM [1])
>>> and the power-policy-manager (PPM [2]). 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 
>> public.
> 
> 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 
>> store.
>>
>> 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
> decisions.

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
policies.
   - surely this is covered by HAL's org.freedesktop.Hal.Device.CPUFreq
interface [1]?

  * 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 [2]
   - 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 [3]

  * 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
session *daemons*.

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?

Rob

[1]
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#interface-cpufreq

[2]
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-battery

[3]
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#interface-device-systempower
>>> 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.
> 
> 
> Thanks,
> 	Holger
> 
> _______________________________________________
> Ohm-devel mailing list
> Ohm-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ohm-devel