On Thu, 2014-01-09 at 17:16 -0800, Andrew LeCain wrote:
> This is another take on exporting significant events from DHCP to
> plugins based on feedback by Patrik Flykt. The original idea was to
> export only the next time of interest that we must be awake for. This
> mechanism didn't allow connman to request that we stay awake for short
> durations (such as during a renew) though, so I've extended it to
> report both the next wake time as well as the minimum time to stay
> awake.
Don't. It gets way too complicated if done this way. It would be a good
idea to start in the plugin end so that we have a decent understanding
of the API to the parts of the system that does the sleeping.
> Additionally, because multiple components within connman might have a
> conflicting state, we must tag requests by component and respect any
> requests to stay awake.
So we'd need to see the part handling IPv4ll and DHCPv6 also. As well as
the mechanism to wake up from sleep for WiFi, ethernet, bluetooth and
cellular, but those are done somewhere else as the system is now asleep?
> The basic idea is creating a notifier that can be called from
> different components with unique identifiers (here we use a
> dhcp_clent*, but anything unique to a component should do) to request
> sleep state.
Again, this would be much easier to start off in the plugin side.
Basically the state of all networking parts (stateless and stateful
IPv6, DHCP and link-local) of all connected or connecting services
should be known to the plugin that can then put the device to sleep.
> void __connman_notifier_sleep_event(void *identifier, bool canSleep,
> time_t valid_until)
Better would be ..._idle_until..., but as you notice the function name
is prefixed by underscores which means it's not available for the code
in ./plugins directory. So no plugin here or how was this planned?
> Any interested plugin will be responsible for aggregating valid votes
> from all unique identifiers and may sleep only when at least one
> identifier which has set canSleep, for no more than the shortest
> duration of validity. If any identifier votes with canSleep clear, the
> system will not sleep for at least that duration. During this sleep,
> any packets intended for the system must be allowed to wake the system
> up.
I don't think voting is a necessary component here. The one with the
lowest idle time always wins.
BTW, please split out the T1, T2 patches from this patch set into a set
of it's own. It's really a different thing from all the rest. And do
have a proper commit message for that one.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
