>> 1. The single_auto_connection() is triggered when new service is created.
>> 2. The timeout call back is used to track the connection state and try the
>sequence items. So this part can be independent with other parts, and make
>implementation simple.
>> 3. The new trigger can refresh the old single_auto_connection().
>
>I think this patch has more complexity than actually needed. I am
>thinking more of something around these lines:
All in all, I believe the patch is just what you wanted. I will do much test
and split the patch and resend again today.
What makes you feel complexity is that I have mixed 3 patches into one. :)
The patch includes
1. patch to implement service_connect(struct connman_service * servcie)
function to connect a service
2. patch to implement service_disconnect(struct connman_service * servcie)
Function to disconnect a service
3. patch to implement single-auto-connect()
The implementation of auto connect
It is too late last night, and I hope to get your feed back quickly, so I did
not split it. :-)
>
> for (i = 0; service_count; i++) {
> if (service[i].favorite == FALSE)
> break;
> if (service[i].state == READY)
> break;
> if (service[i].state == FAILURE)
> continue;
>
> err = connect_service(service[i]);
> if (err < 0 && err != -EINPROGRESS)
> continue;
>
> break;
> }
>
>And we can keep calling this multiple times. Since if a connect attempt
We'd better not keep calling. It can sleep to give out CPU, I chose to use
timeout handler to call this period.
>fails, the state will become FAILURE and we would skip that service the
>next time.
That is just what I have done in the patch.
>This also ensures that user interaction and scan results are
>taken into account during that auto-connect phase.
Using timer handler to give out CPU, other operations can have more chance to
run.
Furthermore, I have let new auto-connect timeout handler refresh the current
timeout one. So
1. If we scan several favorite services at the same time, we have the chance to
merge several auto-connects into one.
2. User operation trigging new auto-connect can terminate the old auto-connect.
So the scan results and user interaction have been taken good care at the patch
>
>So we can trigger this auto-connect on startup and when all states are
>either in IDLE or FAILURE state. For that a global counter could be used
>to make it an inexpensive check.
We have some issue in this:
When booting, we can not know when the booting finished, so every favorite
service with IDLE state will trig the auto-scan. So it is the same to put the
trigger just after new favorite service created which is what I have done in
patch.
In running time when all the sates in IDLE or FAILURE, to trigger auto-scan
will make system more complicated, it may also lead to some race condition
issues. And It will be more complicated involving user operation. Think of user
manually disconnecting the service which is the only connected one. That will
trigger auto-reconnect the same service. That is what we wanted?
For now, trig auto-connect when create new favorite is enough to resolve
current booting and flight mode off issue. We can add other trigger points
later when DD coming, or want to implement always connection feature. ;-)
>_______________________________________________
>connman mailing list
>[email protected]
>http://lists.connman.net/listinfo/connman
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
