[ohm] OHM vs. PPM

[Holger Macht]

On Mo 05. Mai - 18:19:09, Rob Taylor wrote:
> 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?

Because there is no user session or the specific feature is not session
specific, thus can be handled system wide across sessions, users and
desktop.

> Taking things it does from the docs:

Uhm, I think the docs are pretty much outdated. Powersaved's development
lies fallow for a couple of month already due to not fitting with current
upstream policy design. It's destiny is already carved in stone, it will
die.

>  * Four predefined powersave schemes
>   - sounds pretty much like a session/user level decision

Or system administrator 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]?

Of course it is. The powersave daemon just calls the appropriate HAL
methods.

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

It is. But somebody needs to monitor this and needs to take an appropriate
(default) action.

>   - action policy could be system or user defined.

Right, in case there is no user, there's need for a default
configuration/policy.

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

Another outdated documentation section. We're using pm-utils for that.

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

And...outdated ;-) Powersaved in its current implementation is a
standalone 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?

You at least need a good default policy. Something like having the
ondemand governor for CPU frequency scaling set by default by the kernel.

There's the new approach to start the desktop policy agents already in
gdm, but that's just one possible implementation design.

You don't need the policy that early if you're knowing that gdm _will_
run. If you aren't sure, you need a policy before.

I need a solution which works both for Desktop systems _and_ server
systems. People are filing bugs if you don't provide that. At least that's
my experience.


Thanks,
	Holger