Hi Patrik,
On 01/09/2014 02:11 PM, Patrik Flykt wrote:
>
> Hi,
>
> On Fri, 2013-12-13 at 09:34 +0100, Daniel Wagner wrote:
>> static struct connman_notifier session_notifier = {
>> .name = "session",
>> - .service_state_changed = service_state_changed,
>> - .ipconfig_changed = ipconfig_changed,
>> + .service_add = notify_service_add,
>> + .service_remove = notify_service_remove,
>> + .service_state_changed = notify_service_state_changed,
>> + .ipconfig_changed = notify_ipconfig_changed,
>> };
>
> By adding the notify_service_add() notifier, session code just
> duplicates the service hash in src/service.c without any additional
> features.
Not really, it allows to create a complete mapping between services
and sessions. The interface itself doesn't give you that new feature,
but with it I can implement it.
> The current implementation uses only a service state changed
> notifier as a session does not need to know about all services,
We need to maintain at one place a mapping between sessions and which
service is allowed to be used. The first version you reviewed maintained
this list inside struct connman_service. This version moved this mapping
to session.c.
If you don't like to (ab)use the notify API I have no issue with using
explicit calls, .e.g. something like __connman_session_add_service().
> only the
> connected ones (and when they move out of connected state). For example
> all unknown wifi services that happen to be found while scanning will
> not bloat the data structure in session and make the service handling
That is unfortunate but I don't see any other way to achieve my use case.
> simpler as the connected state need not be checked again in session.c.
I don't get that one. We always need to check which state a service is
on all notify service_state_changed.
> Thus I'd drop the service added notifier.
Okay, let me use explicit calls in this case.
> Similar reasoning goes for the service removal notifier. If the service
> is disconnected or even removed, it's of no use for the session code and
> again there is no need to track it anymore as it's unconnected and can't
> be used. This makes it unnecessary for the session code to check service
> state, as only connected services are the ones visible in the session
> code.
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.
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).
cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
