Hi Patrik, On 01/15/2014 12:09 PM, Patrik Flykt wrote: > On Tue, 2014-01-14 at 13:47 +0100, Daniel Wagner wrote: >> When a service is created it wont be announced that it exist via >> service_state_changed(), there is create state event. The same goes >> for the removal. > > Why does session care about each individual service?
Here is what needs to work: AllowedBearers=wifi_6003089c5c40_4775657374576c616e_managed_psk FilterBearers=ethernet_0080c8383895_cable So the first one says, only and only pick the service. The second one says never ever use this one. > When a session > issues a Connect(), service autoconnect is run. Service autoconnect > already works so that it selects one service per bearer type and > connects them in parallel. Yes, and that is okay. No changes needed. What I change is the services which are considered that is all. > The end result is that the session code gets > information on connected services only, not the rest that are of no > interest to it. And again that is okay. No changes needed. I do not change anything there. > For this the normal service notifier is enough. Ah I see what the problem might be. Okay let's step back a bit from the details. To support the above two uses cases the auto connect algorithm has to do some work when a auto connect request is triggered. It needs to find out which available service matches any session configuration. This 'find out' can be done eager (as the current implementation does by counting up or down the bearer type when session changes) or we do it lazy. In both cases we need a list or mapping of services which matches the session configuration. The implementation here does this work the eager approach by updating the service-session list via the notify API. > There is > no way any useful information is provided by tracking all services when > they are added until they are removed, as all the session code does is > asking the service code to try to autoconnect them. I think from your comments you favor to do the lazy approach by handing the filter rules to service.c and it creates the list of service candidates on request (auto connect). Doing lazy has the side nice effect we wouldn't do any work if we get a WiFi scan results adding/removing a bunch of networks. The downside is whenever we trigger auto connect the service-session mapping has to be done. My intuition tells me we should do the work eager and not lazy but without real numbers either approach is a good as the other. >> There is no way to know when a services was added or removed as it is. >> auto_connect_service() asks session.c to give the current list of >> services which are allowed (passed the filtering rules, which are >> currently the AllowedBearers but as I indicated, I need it also as per >> service name). > > If they are needed by service name, then surely the name must be stored > somewhere, right? In that case the upcoming code could actually hand > over also a service name, not just service types. See the few patches on my repo here https://github.com/bmwcarit/connman/commits/policy-services-v7 Anyway the reason why the service-session list into session.c is on your request[1]. After moving the code to session.c it looks much cleaner. So yes I agree with your last request. With your current review I think you prefer to have it all in service.c again. My question is now, what do you want? Is it service.c or session.c? Lazy or eager? cheers, daniel [1] http://www.mail-archive.com/[email protected]/msg14523.html _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
