Wakeup interface concerns (Was Re: changing the enum type)

David Zeuthen david at fubar.dk
Mon Mar 2 08:35:06 PST 2009


(replying separately to this topic)

On Mon, 2009-03-02 at 16:10 +0000, Richard Hughes wrote:
> > (cf. the .Wakeup interface)
> 
> What's wrong with it?

OK, so I'm looking at

http://cgit.freedesktop.org/DeviceKit/DeviceKit-power/tree/src/org.freedesktop.DeviceKit.Power.Wakeups.xml?id=DeviceKit-power-006
(using a link to version 006 to preserve history for the archives)

This interface is not really well-designed. I tried to express that here

http://lists.freedesktop.org/archives/devkit-devel/2009-February/000104.html

The main concern is that the presence of the signals leads you to
believe you can just connect to connect to the bus and then they get
delivered to you with some sane frequency. 

Of course this won't work because then the daemon would have to wake up
all the time. Which coincidentally it used to do until I pointed that
out.

There's also a (very slight) concern the data carried in the signals may
be privileged information; you may not be authorized to get this
information depending on how your system is set up.

So the signals need to go.

The other observation to make, once you realize that signals won't work,
is that having multiple different callers will cause measurement issues.
They literally step on each others toes with the way this work.

Another observation is that the wakeup interface is mostly just a power
user feature, it's really only something you need if you want a GUI-ish
powertop utility like you did in g-p-m.

So it's fine to only allow one caller.

So the proposal would be

 o  get rid of the signals

 o  make GetData() also return
     - the data in the signals
     - amount of msec since this was last read
    in addition to the array of structs per process

 o add methods to claim/release the wake up interface
    - StartReadingData (OUT string cookie)
    - StopReadingData (IN string cookie)
   and only allow a single caller to do this. Remember to
   watch for disconnects too.

and then users of this API would do

 cookie = StartReadingData ();
 while (<displaying dialog>)
   {
     stuff = GetData ();
     <render stuff on screen>
     sleep (<poll frequency>);
   }
 StopReadingData (cookie)

     David





More information about the devkit-devel mailing list