Thanks for the great feedback Patrik! I agree that really all we need is the next major event (T1 or T2 expiring) The plugin is pretty simple and just chooses the earliest expiration to wake up. I included all of these statistics for completeness, but if you think it is better to only provide the next wakeup then that will make the plugin even simpler. However, we will also need some indication that it is okay to sleep. For example, when we send our renewal packet at T1 expiration, we need to keep the system awake for a while to wait for the timeout and and recalculate T1, set T2 timeout, etc.
I would suggest then that we need two changes to the API: - void (*wakeup_changed) (struct connman_ipconfig *ipconfig); -- notifier called whenever get_next_wakeup will return a valid sleep value. This will happen whenever we can safely enter sleep, such as a successful renew, successful rebind, or expired lease. - time_t connman_ipconfig_get_next_wakeup() -- added to ipconfig.h to provide the next wakeup time (min(T1, T1 retry, T2, lease_expiration);) Because of the accounting of T1 and T2 in gdhcp, it would be easiest to return an absolute time. If the time returned is in the past then assume we should remain awake until we get another wakeup_changed notifier event. (I have not sent the plugin because it's mostly system specific code, aside from registering itself as a plugin, subscribing to the settings_changed notifier, and the above mentioned logic to select the shortest timeout from all ipconfigs it gets notifications from. If you'd like I can strip out our system specific code and provide a bare bones example) I will make these changes and submit a more functionally split patch set. -Andrew On Tue, Jan 7, 2014 at 1:19 AM, Patrik Flykt <[email protected]>wrote: > > Hi, > > On Mon, 2014-01-06 at 18:09 -0800, Andrew LeCain wrote: > > > > As mentioned in discussion of RFC "Publish DHCP statistics to dbus" on > > 10/31, we have a usecase that requires knowledge of dhcp statistics > > (specifically lease duration and lease time) to make power management > > decisions for the system. As suggested by Marcel, we've implemented > > this as a plugin, however there are a few changes to the core and api > > needed to expose this data to the plugin. > > > > Specifically, we need accessors to request the statistics about the > > lease and a notifier event to trigger every time the lease changes > > (renew, rebind, etc) I have implemented this as generically as > > possible to allow other plugins that need information about the lease > > to use this information as well. > > Exposing DHCP data will not be necessary. > > Your system wants to sleep as long as possible. Thus ConnMan needs to > inform the system of the next time when an event of importance takes > place. From the DHCP perspective, this is when ConnMan needs to get back > to the server to renew it's lease. Only the time of the next event needs > to be communicated, not the full spectrum of related data. > > Start with the plugin itself. It surely communicates over D-Bus to the > rest of the system and is quite simple. As input for the D-Bus > communication the time of the event is needed, either absolute or > relative. > > DHCP is one source of such information, but the individual DHCP timer > values are not. Starting off with an acquired lease, the system can > sleep until Renewing timeout T1 minus the time it takes to wake up from > whatever deep sleep the system is in. That computation is part of the > system and not any of ConnMan's concern, though. > > If reacquiring a DHCP lease after waking up is successful, T1 gets > recomputed and the system can sleep until T1 again. If it didn't > reacquire the DHCP lease, either a newly recomputed T1 timeout, T2 > timeout or expiry timeout is next. Thus the plugin needs to be informed > of the minimum time of these three events and report that over D-Bus. > Same thing if T2 timer hits, at that point T1 is of course cancelled. So > the full set of DHCP values is not needed, only the time of the next > event. > > The other funny thing is that some fixes may be needed for all the T1, > T2 handling, at least the code does not take the T1 or T2 timeouts into > account. > > So perhaps you could send the plugin first and then work backwards from > there to extracting the next timeout for any DHCP event? > > Cheers, > > Patrik > > > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
