DeviceKit-power and latency control
hughsient at gmail.com
Tue Nov 11 04:08:42 PST 2008
On Mon, 2008-11-10 at 12:26 -0500, David Zeuthen wrote:
> If a cookie is what we want (and I think we do), we shouldn't implement
> it this way. Second, everything in a process share the D-Bus connection
> so this wouldn't be a very good cookie anyway.
Agreed, I've changed the interface.
> The point is really that if you're providing this for an admin-like user
> interface (and we are) then it's likely that user interface will need
> that kind of information. So better expose it.
Right, okay, I'll start adding data like uid and executable.
> Why wouldn't the admin just use the same method? I'm not sure why we
> need two separate methods. I mean, with a CancelLatencyRequest() and
> proper user interface the admin can just remove requests that way.
Nahh, the admin interface is "sticky" i.e. the admin can issue the
request, disconnect and the the setting is persistent across reboots and
sessions. The user request gets cleaned up on disconnect.
> > > 7. GetLatency() is probably the right name since it will be computed
> > > from the set of outstanding requests. What does it return if there are
> > > no outstanding requests?
> > I guess -1, although that needs to be in the docs.
> Isn't there a default latency we can read from somewhere? If possible, I
> definitely think we want to return something meaningful instead of e.g.
> -1 meaning "not set".
The (yet to be written) config file, /etc/DeviceKit-power/defaults.conf
> I mean, with the system running and all, I think
> there is *some* default latency set even when no application has asked
> for it...
Right. Thanks again for the review.
More information about the devkit-devel