Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH] peer: Do not notify state changes when peer is
not registered yet (Daniel Wagner)
2. Re: race between __connman_service_connect and
config_notify_handler (Daniel Wagner)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Dec 2017 09:16:35 +0100
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] peer: Do not notify state changes when peer is
not registered yet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Vasyl,
On 12/07/2017 12:38 AM, Vasyl Vavrychuk wrote:
> Since?peer->path is putted to NULL only in?peer_free, this seems to be
> dangling pointer (connman_peer *peer) situation. Therefore checking for
> peer->path is not enough.
Good point. I was just shooting into the dark, because I couldn't really
test it.
> I am not sure what is better solution to deal with it:
> 1. Add?connman_peer_ref to?manage_peer_error and?connman_peer_unref
> to?report_error_cb.
> 2. Add to peer_free code that looks into agent's?pending and queue
> fields and finds?connman_agent_request associated with removed peer and
> cancels either request or processing of its response.
> 3. As a user_context pass to?connman_agent_report_error_full method peer
> ID instead of pointer to peer and in?report_error_cb_t lookup peer by
> this ID.
>
> Could you please suggest what is better option.
Since we seem to have a race I would choose option 1) because it make
sure, that we have always the complete peer object valid. If we shortcut
on the report_error_cb path we might miss something else again.
Could you try this and see if everything is still okay after the added
ref/unref?
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 7 Dec 2017 09:32:11 +0100
From: Daniel Wagner <[email protected]>
To: Vasyl Vavrychuk <[email protected]>
Cc: [email protected]
Subject: Re: race between __connman_service_connect and
config_notify_handler
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Vasyl,
On 12/06/2017 11:07 PM, Vasyl Vavrychuk wrote:
> Hi, Daniel,
>
> Thanks for feedback. Please find my comment below.
>
> On Wed, Dec 6, 2017 at 11:12 PM, Daniel Wagner <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Manager:
>
> ? ? ? ? void LoadProvisioning(object service, string provisioning)
> ? ? ? ? ? ? ? ? Upload a provisioning for given service.
>
>
> I think that besides setting this parameters to connman, we should
> provide possibility to get this parameter from connman. It is because
> user may want to find out what is current settings.
>
> How about just to have in service api property
>
> ? string Provisioning.
>
> which is in XML (or maybe JSON) format. This is very simple rework of
> what Lucio implemented and looks like it suits requirements of Marcel.
The main reason I was pondering why to add it to the Manager API is that
we might now have the service object there. So it's about the use case
when the user wants to add a provisioning for a service which is not yet
there, e.g. WiFi network is not yet in reach.
But then my API proposal has the same problem. We would need to know in
advanced the object path. And that is something we really don't want to
do. The path should be considered as random strings.
I think we have a problem with the different concepts here. Thinking
load: an entry in the provisioning file is identified either via MAC or
SSID, IINW. If we follow this we should reuse those keys for an entry.
Would that make sense?
Thanks,
Daniel
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 26, Issue 6
**************************************
