Hi,
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.
The next issue that comes to mind is how a system "sleep API" like this
can be generalized to be useful for other daemons. It surely would help
if the sleep daemon was open source or if similar APIs were in use by
others so that it could be tested outside this particular use case
setup. If not, it's upstream maintenance will be quite impossible.
Cheers,
Patrik
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
