Hi Grant, >>> 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?
my general rule is something that is useful for an end-user / UI to present, that should be exposed via the D-Bus API and be configurable. Something that human being would change (or sadly have to change). For system related things we prefer plugins or some dedicated interface. ConnMan has internally some functionality like the notifier. We used that back in the days for Intel specific power management. So the plugin talked to power management daemon and informed it about state changes. So we might should be looking at extending the core with the basic functionality so it can be implemented as a plugin. Regards Marcel _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
