Re: [gpm] Common system interface for PowerManagement

[Holger Macht <hmacht suse de>]

Hi,

anyone having further comments on this?

So people involved in the discussion here on the list agree on a system
level interface org.freedesktop.Policy.*? In the first place, I don't care
about FUS or ,ultiseat. My request was just a proposal of a system
interface for a single user desktop or servers. I think this single
interface is sufficient in the first place, we also could add sublevels or
methods to such an interface if we see that we need it in future. If
nobody involved in this discussion objects, I would propose this on
xdg freedesktop org 

Thanks,
	holger

On Fri 06. Oct - 15:26:55, Holger Macht wrote:
> On Thu 05. Oct - 21:21:58, David Zeuthen wrote:
> > On Fri, 2006-10-06 at 00:16 +0200, Holger Macht wrote:
> > > > If the sysadmin denies policy daemons to certain things on behalf of
> > > > certain users then he better make sure that either 
> > > > 
> > > >  a) the system-wide instance of a policy daemon is doing what he wants
> > > >     even if a desktop-wide instance of a daemon is running; e.g.
> > > >     continue to run and only do a subset of the tasks it's doing
> > > >     when running normally... (e.g. when no-one is logged in). One could
> > > >     build this into the policy daemon code you have running system-wide
> > > >     e.g. powersaved would continue to do certain things even when g-p-m
> > > >     is running. Or system-wide g-p-m would do certain things even when
> > > >     klaptopd is running.
> > > 
> > > Yes, powersaved will do it this way because he still does things that
> > > should not be or are not in HAL and which don't require user
> > > interaction/configuration. But these are things which don't bother the
> > > desktop user like hard disk settings, etc.
> > 
> > Actually such non-tweakable things are supposed to be handled by HAL's
> > SetLowPower() method (which invokes pm-setlowpower in a pm-utils future)
> > but that's another thing. 
> 
> Actually one could also think of if it's non-tweakable, you do not even
> need to call SetLowPower() ;-) But it was just one example.
> 
> > 
> > (Another point is that using hdparm / sdparm etc. for hard disk power
> > management is pretty dangerous IIRC. Ideally the kernel drivers for the
> > hard disk exposes knobs in sysfs but that haven't happened yet.)
> > 
> > > >  b) that the system is already configured in a way he wants without
> > > >     having to run a daemon.
> > > 
> > > But what does a administration actually do when he for instance doesn't
> > > want users to change the CPUFreq policy. He denies the privilege
> > > hal-power-cpufreq from /etc/PolicyKit/privilege.d/hal-power-cpufreq for
> > > all users. The system daemon can't know that the desktop application
> > > taking over the common interface is actually not allowed to care about
> > > CPUFreq. And you still want to care about because you might want to adjust
> > > it on specific events, for instance battery removal.
> > 
> > Another way to constrain the users is to use gconf lockdown (or KDE
> > kiosk mode equivalent). But it's not really secure, it'll just make sure
> > that user can't use g-p-m (or KDE equiv) to change the value - people
> > can still use dbus-send to tweak it. It's really a corner case though I
> > think. 
> > 
> > Or maybe the admin just uses a system daemon that does cpu frequency
> > scaling.
> 
> Well, but that's not the way distributions work. If the admin changes a
> config file because he doesn't want users to do specific things, the
> system has to work nevertheless. Or we would have to remove the
> possibility that a admin can do this.
> 
> And acutally I have another example. If the admin forbids the users to
> modify the action that is executed when pressing the power button, which
> is a logical proposition, the system level application still has to care
> about button presses, no? But when g-p-m grabs the system interface, it
> has no possibility to know whether it still has to care about button
> presses. Yes, you can argue that if a admin does this, he also has to care
> about the consequences, like adding actions to acpid or such, but that's
> not perfect. Ideally everything should work nevertheless.
> 
> > 
> > Or perhaps the admin uses a pm-utils hook on SetLowPower().
> > 
> > Actually I've got another idea, see re adding locking infrastructure to
> > HAL.
> > 
> > > > Realistically I think it's not going to cause problems - at the end of
> > > > the day all policy manager daemons should support the same feature set
> > > > anyway. Perhaps our spec could mention what minimum feature set a policy
> > > > daemon should implement in order to qualify to take the name?
> > > 
> > > Yes, this is a good idea. So one doensn't have to mess with our socalled
> > > 'capabilities'. We had that because we didn't imply that all
> > > PolicyManagers have the same set of features. But that's a constraint we
> > > should make.
> > 
> > Right. I thought about splitting org.freedesktop.PolicyManager.Power
> > into several sub names but it seems like extra complexity for little or
> > no gain.
> 
> Still thinking about this in regard to the above written. I think we need
> a good solution for this.
> 
> > 
> > > > There's also the case of fast user switching and multi-seat when you
> > > > have > 1 session on the box. Then it's not unrealistic that you have,
> > > > say, three instances of g-p-m and one instance of kpowersaved running in
> > > > the four sessions on the box. 
> > > > 
> > > > How we synchronize this is an interesting question. My thinking for this
> > > > includes 
> > > > 
> > > >  - making HAL deny calls if the session that is not active on a console
> > > >    (will fix fast-user switching; e.g. g-p-m on inactive session will
> > > >    not change the LCD backlight because the inactive session becomes
> > > >    idle.)
> > > 
> > > In case of LCD backlight, agreed. But you have to specify which methods
> > > are f-u-s relevant.
> > 
> > Yeah. I'd say any method that touches a shared resource needs this
> > treatment.
> > 
> > Other examples are Suspend() and Hibernate(). Basically all calls on HAL
> > that causes side effects needs to be denied for inactive sessions. In
> > PolicyKit terms we should require the privilege
> > 
> >  desktop-console-visible
> > 
> > rather than just
> > 
> >  desktop-console
> > 
> > so that'll be easy to fix once we have the appropriate infrastructure.
> 
> Generally, this looks good. Can't it be the case that multiple sessions
> are active to the same time?
> 
> > > I think of a session starting up, grabbing the system interface and thus
> > > caring about CPUFreq. Later on, this session might currently not be active
> > > but this session still has to care about CPUFreq.
> > 
> > Well, the session that is active should control the CPUFreq policy I
> > think. So calls on CPUFreq should require desktop-console-visible. 
> 
> But sometimes you only want only root to control it ;-)
> 
> > 
> > Btw, we'll also need to teach desktop policy daemons about when they
> > become active / inactive. Such that they can call into HAL to
> > reconfigure the settings for both LCD and CPUFreq. But that's another
> > point. And only relevant for f-u-s of course.
> 
> Well, just sending out a signal applications catch come to my mind.
> 
> > 
> > > >  - for suspend-when-idle have some way of having a session veto the
> > > >    request to suspend the machine. Will most likely include registering
> > > >    a veto handler somehow and having each veto-handler ACK or NAK the
> > > >    request.
> > > 
> > > Doesn't this require an interface on the system bus all sessions have
> > > access to?
> > 
> > Yes, I was thinking of putting this in HAL to guard methods on shared
> > resources such as on the .SystemPowerManagement and .CPUFreq interfaces.
> > It's really just about arbitrating access to shared resources.
> > 
> > So I think any HAL interface that cause side effects (e.g. any interface
> > that is not .Device) should export logic to do this. Each interface
> > should support the following methods
> > 
> >  ExclusiveLockObtain(OUT string cookie)
> >  ExclusiveLockRelase(IN string cookie)
> > 
> >  SharedLockObtain(OUT string cookie)
> >  SharedLockRelease(IN string cookie)
> > 
> >  (these locks are also tracked via NameOwnerChanged)
> > 
> > e.g. org.fd.H.Device.CPUFreq and org.fd.H.Device.SystemPowerManagement
> > implements these methods. Both of them.
> 
> Wouldn't it be better to have an additional layer in HAL wich cares about
> locking so that not every addon has to implement these methods on its own?
> 
> > The "exclusive lock" is a binary non-recursive semaphore. Only one
> > caller can hold it at any time and it will lock out any other caller
> > from invoking any methods on the interface on the object including
> > obtaining the lock. 
> > 
> > Use-case: system power management daemon claims the exclusive lock on
> > the CPUFreq interface. Hence no session daemon can call into that
> > interface. So in the multi-seat example this requires the system power
> > management daemon to actually do this but only if there are > 1 seats
> > active.
> 
> I'm always coming back to the privilege case. In current PolicyKit
> implementation, there's no way for root to check if a users in general are
> allowed to do something. Of course, it can check all users for a specific
> privilege. But maybe libpolkit could provide a convenient function here...
> 
> > The "shared lock" is recursive semaphore. Any caller can claim it. If
> > the lock is held by someone, callers are prohibited from invoking
> > methods on the interface except for SharedLockRelease().
> > 
> > Use-case: Multi-seat. Each session daemon holds the shared lock when the
> > session is not idle. Only when the session becomes idle (e.g. when it's
> > OK to suspend) they release the lock and then call Suspend(). This
> > guarantees that the last session that becomes idle does the Suspend()
> > call.
> 
> You will still need a system service having the exclusive possibility to
> finally do the suspend, shutdown whatever. Because if your battery runs
> low, and the sessions are doing something wrong or need too much time to
> finish their tasks, you need a last instance telling when time ran out.
> 
> > I think actually this might make sense. 
> > 
> > What do you think of this? It shouldn't be too hard to implement in HAL
> > via some utility functions.
> 
> Yes, I think so, too, although I have to apologize that I did not spend
> too much time in thinking about multiseat yet.
> 
> 
> Regards,
> 	Holger
> _______________________________________________
> gnome-power-manager-list mailing list
> gnome-power-manager-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list