DeviceKit-power and latency control

[David Zeuthen]

On Fri, 2008-11-07 at 13:34 +0000, Richard Hughes wrote:
> On Thu, 2008-11-06 at 12:26 -0500, David Zeuthen wrote:
> > On Thu, 2008-11-06 at 16:47 +0000, Richard Hughes wrote:
> > > I’ve put an interface file up here:
> > > http://people.freedesktop.org/~hughsient/DeviceKit-power/gtk-doc/Latency.html
> > 
> > Some comments
> > 
> > 1. Regarding GetRequests() returning a(ussi), e.g. an array of
> > 
> >     - pid, connection, type, value
> > 
> > why is the connection necessary?
> 
> If more than one process has two different requests -- mainly so the
> application didn't have to track it's own requests. For instance, you
> could have one request from two different GObjects. Think of it like a
> cookie.

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.

(In general, we should avoid exposing transport details like the D-Bus
connection as people might want to wrap our D-Bus interface behind a RPC
thing like func / SOAP / XML-RPC etc. for cluster-like systems.)


> > For that you want a bit more than information actually, you need
> > something like this
> > 
> > http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device.FilesystemListOpenFiles
> 
> With the PID, can't we get all this other stuff?

Today you can get this on Linux, in the future, who knows if you can
read /proc/<pid>/ if it's owned by another user. 

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.

> > that uses more suitable names / icons for representing the applications
> > with active outstanding requests. You probably also want to lock this
> > method down using PolicyKit and default to granting the authorization to
> > active local sessions.
> 
> You think we need to lock down this method? Surely anyone can read /proc
> and get essentially the same data.

Maybe not. But we need to lock it down in case /proc can't be read in
the future.

> > 4. What's the difference between SetLatency() and SetMinLatency()
> > anyway? When would I use on over the other?
> 
> The latter would be set by an admin to over-ride the latency request for
> applications.

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.

> 
> > 5. How do I undo a latency request? Probably the Request* methods needs
> > to return a cookie and we need a CancelLatencyRequest() method to cancel
> > it that you pass the obtained cookie in.
> 
> I figured the connection would be disconnected or the client could do
> Request(-1). If this is done per-connection, I don't think we need to
> return a cookie.

I think we want a cookie.

> > 6. Should we return the cookie in the GetRequests() thus allowing other
> > clients to cancel a request? Maybe
> 
> I hadn't thought of that. That's probably the exact sort of thing you
> would do on the admin interface. Returning a proper cookie would allow
> us to do that.

Right, I think that makes sense.

> > 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". I mean, with the system running and all, I think
there is *some* default latency set even when no application has asked
for it...

     David