[RFC 1/2] doc: Add service provisioning method in Manager API
--- doc/manager-api.txt | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/doc/manager-api.txt b/doc/manager-api.txt index 743ba18..430dec9 100644 --- a/doc/manager-api.txt +++ b/doc/manager-api.txt @@ -117,6 +117,22 @@ Methodsdict GetProperties() Possible Errors: [service].Error.InvalidArguments + object ProvisionService(dict properties) + + Provide a configuration for existing services. + + Configuration property must be provided that contains + the actual configuration as a string. It follows the + same format as configuration files, see + config-format.txt. An exception to this format is + that only one service can be provisioned in a single + call. + + When successful this method will return object + path of the service object. + + Possible Errors: [service].Error.InvalidArguments + object ConnectProvider(dict provider) Connect to a VPN specified by the given provider -- 1.7.0.4 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH v2] dnsproxy: Fallback to resolv.conf if dnsproxy fails
Hi Kalle, On Mon, Jan 31, 2011 at 04:28:19PM +0200, Kalle Valo wrote: Kalle Valo kalle.v...@canonical.com writes: Daniel Wagner w...@monom.org writes: In case dnsproxy can't create the socket listener we should fall back to resolv.conf. Reported by Kalle Valo kalle.v...@canonical.com dnsproxy now works as it did earlier and dns works even if I had dnsmasq accidentally running. Thanks a lot for fixing this. Just noticed that this is not yet applied and, to my dismay, it also missed 0.68 release :( Is there anything wrong with the patch or is just in the queue? Is there anything I can do to help? It's been pushed now, it just got lost on my patch queue somehow. Sorry for the glitch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH v2] dnsproxy: Fallback to resolv.conf if dnsproxy fails
Samuel Ortiz sa...@linux.intel.com writes: Hi Kalle, On Mon, Jan 31, 2011 at 04:28:19PM +0200, Kalle Valo wrote: Kalle Valo kalle.v...@canonical.com writes: Daniel Wagner w...@monom.org writes: In case dnsproxy can't create the socket listener we should fall back to resolv.conf. Reported by Kalle Valo kalle.v...@canonical.com dnsproxy now works as it did earlier and dns works even if I had dnsmasq accidentally running. Thanks a lot for fixing this. Just noticed that this is not yet applied and, to my dismay, it also missed 0.68 release :( Is there anything wrong with the patch or is just in the queue? Is there anything I can do to help? It's been pushed now, it just got lost on my patch queue somehow. Sorry for the glitch. No problem. Thank you for taking it now. -- Kalle Valo ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 01/28/2011 10:39 PM, Grant Erickson wrote:
diff -aruN a/src/stats.c b/src/stats.c
--- a/src/stats.c 2011-01-28 13:20:49.248299633 -0800
+++ b/src/stats.c 2011-01-28 13:19:44.824306025 -0800
@@ -223,10 +223,18 @@
TFR(close(file-fd));
file-fd = -1;
- if (file-history_name != NULL)
+ if (file-history_name != NULL) {
g_free(file-history_name);
- g_free(file-name);
- g_free(file);
+ file-history_name = NULL;
+ }
+
+ if (file-name != NULL) {
+ g_free(file-name);
+ file-name = NULL;
+ }
+
+ if (file != NULL)
+ g_free(file);
}
I think the last check (file != NULL) is not necessary, because we do
derefence it several times above.
cheers,
daniel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up)
On 1/31/11 1:47 AM, Daniel Wagner wrote: On Fri, Jan 28, 2011 at 08:13:28PM -0800, Grant Erickson wrote: As far as I can see, the stats mapping is not published or shared outside of connman. If so, there's no reason to map it SHARED versus PRIVATE. From the mmap man pages: MAP_SHARED Share this mapping. Updates to the mapping are visible to other processes that map this file, and are carried through to the underlying file. The file may not actually be updated until msync(2) or munmap() is called. MAP_PRIVATE Create a private copy-on-write mapping. Updates to the mapping are not visible to other processes mapping the same file, and are not carried through to the underlying file. It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. The reason for picking MAP_SHARED was to be sure the changes in buffer really hits the file. I read that MAP_PRIVATE does not garantee this. This is reason I was picking MAP_SHARED together with msync. Daniel: Thanks for the clarification on the rationale for choosing MAP_SHARED. I'll have to do some digging in to determine why MAP_SHARED fails on the ARM/Linux 2.6.32 kernel. It might be beneficial to add the above comments to the source file for future reference. Best, Grant ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
