[ohm] OHM vs. PPM

[Holger Macht]

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 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