Re: [gpm] Common system interface for PowerManagement

[Holger Macht <hmacht suse de>]

On Wed 04. Oct - 22:32:46, David Zeuthen wrote:
> On Wed, 2006-10-04 at 18:22 +0200, Holger Macht wrote:
> > Gnome-power-manager's and kpowersave's job as a policy decision maker is
> > good, but it's only valuable when X is running. So a system level daemon
> > which acts as a policy client before X comes up and which is started at a
> > very early stage in the boot process needs to know when another client,
> > such as gnome-power-manager, takes over the policy part or exits.
> > 
> > I'm currently facing this proplem with powersaved, which has to start up
> > very early, but has to ignore some features like CPUFreq as soon as
> > another client like gnome-power-manager or kpowersave start up. So I'm
> > looking for a common solution all might agree on...
> > 
> > Therefore I propose a common interface on the system bus policy decision
> > makers 'grab' with different priority.
> > 
> > It works as follows:
> > 
> >   1. System boots
> >   2. System level daemon like powersaved starts up and grabs an interface
> >      org.freedesktop.PowerManager (or similar) on the system bus with low
> >      priority and the D-Bus flag DBUS_NAME_FLAG_ALLOW_REPLACEMENT
> > 	      
> >      Something like:
> >  
> >      dbus_bus_request_name(system_connection, "org.freedesktop.PowerManager",
> > 	                   DBUS_NAME_FLAG_ALLOW_REPLACEMENT, &dbus_error);
> > 
> >   3. X starts up, a user logs in (or even in gdm) and gnome-power-manager
> >      is started. g-p-m requests this name on the system bus with high priority:
> > 
> >      Something like:
> > 
> >      dbus_bus_request_name(system_connection, "org.freedesktop.PowerManager",
> > 	                   DBUS_NAME_FLAG_REPLACE_EXISTING, &dbus_error);
> > 
> >   4. The system level daemon automatically releases the interface, gets
> >      queued on it and from now on knows that there is another client, and
> >      doesn't care about CPUFreq, etc. anymore.
> 
> There might be a small race here... though IIRC D-Bus can actually do
> this for you (cf. REPLACE_EXISTING) if you pass the right option. Have
> you experimented with this?

Yes, I did and it worked. I don't completely understand what you mean with
racy here, can you elaborate a bit, please? Of course, if you would have
two 'higher priority' policy managers starting to the same time, the
faster one with get the interface. As stated in 2. and 3. you just have to
pass the right option to dbus_bus_request_name.


> 
> >   5. As soon as g-p-m exits, segfaults ;-), X shuts down or whatever, the
> >      system level daemon automatically regrabs that interface and
> >      therefore can care about CPUFreq and stuff until the client restarts
> >      or another client starts up.
> > 
> > This behaviour would actually mean a oneliner in g-p-m to request the
> > system interface. It even doesn't have to care about the return
> > value. This would save me a lot of problems and patches ;-)
> 
> Notably it will work the other way around too. For Fedora I plan to
> start g-p-m via an init script so if e.g. KDE's powersave applet can do
> the same that'll work too when a Fedora user logs into KDE.. yes?

Of course it will. The application started on boot just grabs the
interface with low priority (ALLOW_REPLACMENT). From a priority
standpoint, both a KDE and a GNOME applet have the same high priority, so
they will always grab the interface when they pass REPLACE_EXISTING.

> 
> > What do you think?
> 
> Sounds good to me, I proposed something very similar right here
> 
>  http://bugzilla.gnome.org/show_bug.cgi?id=356174
> 
> with just using a wrapper in front of the daemon. If you're right about
> no race when making the system bit release the interface when the
> session bit requests it... then we probably don't need it.

Yes, that's something similar, although the PauseService() method you are
proposing are not needed IMO. The low priority daemon can check whether it
still possesses the interface, and if not, do nothing. It can just sleep
and automatically (without any code) regrabs the interface when the higher
priority app releases it.

> 
> Btw, this is reusable for other policy daemons too (g-v-m, nm-applet and
> KDE equivalents) without too many code changes except for supporting an
> option "--headless". But my proposal is mostly just an implementation
> detail. 
> 
> Would be good with a generic spec proposed on xdg-list fd o about this
> that defines the names
> 
>  org.freedesktop.PolicyManager.Power
>  org.freedesktop.PolicyManager.Network
>  org.freedesktop.PolicyManager.Volume
>  ...

Hm, I'm not sure if such a grab-regrag mechanism is actually enough for
all cases. As soon as the system interface is grabbed by a higher level
desktop application, the first started application consedes entirely all
responsibilities to the desktop application, although it doesn't know yet
if the desktop user actually possesses the required priviliege to care
about that. And what happens if the desktop application isn't allowed or
it is forbid by the admin to care about some tasks? What about the
administrator forbidding users to control CPUFreq but allowing them to
assign keys to actions such as shutdown? So this interface wouldn't be
enough then. If the the user is not allowed to control CPUFreq, even
though there has to be an application caring about this nevertheless. Hm,
just thinking...

[Just a related note: What I had (and recently removed) in regard to
kpowersave/powersaved was some kind of capability management. Kpowersave
requested some capabilities from powersaved and powersaved told kpowersave
for what it is allowed to care]

> 
> (prefer to use the prefix PolicyManager otherwise we'll clash with
> org.freedesktop.NetworkManager when implementing this for the networking
> bits). I think it might be as easy as just pasting your original email
> in and generalizing it a bit further.
> 
> On a different but related note. Said spec could also define the
> interfaces that were proposed here
> 
>  http://lists.freedesktop.org/archives/xdg-list/2006-May/008139.html

Unfortunatelly the discussion following this post was not very
productive. And rereading the proposed interfaces, I'm still doubt the
need of them. But yes, this is a different discussion.


Regards,
	Holger