Marcel, Patrik: I've been working on getting the changes I've made into a suitable plugin.As you mentioned, there will still be some changes needed to export the information through the connman API to the plugin, and I wanted to ask your opinion on how is best to do that.
To me, the most obvious way is to use the ipconfig_changed notifier channel to fire off events whenever the dhcp state changes. To export the needed state, we would then need to add API functions to request the current DHCP state and relevant timeouts to ipconfig.h. We could either add specific getters or just expose the definition of the connman_ipconfig struct in the header. Unfortunately, I can see how this would add a lot more coupling between the DHCP module and the the ipconfig structure, so I can understand not wanting to do that. The other option would be adding a new notifier channel specifically for DHCP. We could then collect all the accessors into a new header file, but on systems with multiple interfaces, we would need to keep the link between the ipconfig and the associated lease, etc. If you can let me know what you think the better approach is (or another that I might not have seen) that would be awesome. Thanks -Andrew On Mon, Nov 4, 2013 at 9:32 AM, Marcel Holtmann <[email protected]> wrote: > 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 > [email protected] > https://lists.connman.net/mailman/listinfo/connman > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
