On Nov 4, 2013, at 12:20 AM, Patrik Flykt wrote: > On Fri, 2013-11-01 at 13:54 -0700, Andrew LeCain wrote: >> >> We do indeed have a sleep manager that will put our system to deep >> sleep/suspend. This sleep manager also uses the RTC to schedule a wake >> for >> future tasks. However, the wifi chip we use performs suspend-idle >> association and is configured with wake-on-WLAN filters to wake the >> host >> for certain network traffic addressed to the device. This allows us to >> keep >> a consistent association to the network despite the primary processor >> being >> asleep. > > Indeed I suspected this to be the case. Thanks for the explanation! > >> Unless the DHCP lease statistics are known. it's not possible for the >> sleep >> manager to schedule wakeups to renew the DHCP lease. If there are no >> scheduled wakeup events that occur during the renewal period of the >> lease >> then we will lose our lease and no longer are woken up by packets >> addressed >> to us. Additionally, we don't want to suspend in the middle of a DHCP >> renewal, and therefore need to be able to query the DHCP state from >> our >> client. It doesn't appear that the session api provides this >> information. > > The API does not provide this information as it really is not a useful > metric. > > What you actually must do is a separate plugin in plugins/ that properly > takes care of negotiating sleep states with this external daemon. This > way also other events considered important enough can be taken care of > later on. With a specific plugin it will be clear what is going on; > extra properties that have no direct connection with or used by anything > else have a tendency to be plainly broken or just removed. Adding DHCP > stats that are very important but implicit in their nature for a > specific use case is not the way forward.
Plug-in or not, DHCP will have to expose some state. In the proposal on the table, that exposure is via the IPv4 dictionary. In the plug-in counterproposal, some API provided exposure will need to be provided such that the plug-in may use to negotiate with the external daemon. > The next issue that comes to mind is how a system "sleep API" like this > can be generalized to be useful for other daemons. This sounds like a nice opportunity for future architectural enhancement; however, it seems a bit out of scope based on the proposal on the table. In a "CanSuspend" / "WillSuspend" type registration entity within connman to support something like this, do you envision anything beyond DHCPv4 would register with it? Best, Grant _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
