* Re: [PATCH] build: use -lrt for clock_gettime on glibc < 2.17
From: Johan Hedberg @ 2013-09-10 7:55 UTC (permalink / raw)
To: Dirk-Jan C. Binnema; +Cc: linux-bluetooth, Dirk-Jan C. Binnema
In-Reply-To: <1378454956-26605-1-git-send-email-djcb.bulk@gmail.com>
Hi Dirk-Jan,
On Fri, Sep 06, 2013, Dirk-Jan C. Binnema wrote:
> From: "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl>
>
> glibc before 2.17 (e.g., fedora 18) requires -lrt for clock_gettime;
> add -lrt where needed in that case.
> ---
> Makefile.am | 2 +-
> configure.ac | 6 ++++--
> 2 files changed, 5 insertions(+), 3 deletions(-)
It seems Marcel went ahead and applied his own patch for this (I think
he didn't realize there was a pending one here). Could you check if
latest git now works for you?
Johan
^ permalink raw reply
* Re: [PATCH] build: use -lrt for clock_gettime on glibc < 2.17
From: Dirk-Jan C. Binnema @ 2013-09-10 7:20 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <4A735792-B4D7-468A-A61A-488F605AAB30@holtmann.org>
marcel@holtmann.org writes:
> Hi Dirk-Jan,
>
<snip>
>
> so I fixed this upstream a lot simpler by always checking for
> clock_gettime in -lrt. Can you check if that works for you. On an
> older Debian test box it just works fine for me.
Sure, that works; but that's equivalent to the first patch I made... I
only made the more complicated one after your comment:
,----
| > +AC_SEARCH_LIBS(clock_gettime,rt)
|
| I do [not] like this since this now it links everything with -lrt even if it
| is not needed.
`----
AC_SEARCH_LIBS doesn't add -lrt if it's not needed, so I interpreted
your comment as you not wanting -lrt in parts of the code that don't
need it.
Anyway, good it works now...
Thanks,
Dirk.
--
Dirk-Jan C. Binnema Helsinki, Finland
e:djcb@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Luca Coelho @ 2013-09-10 6:28 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
On Mon, 2013-09-09 at 15:23 -0400, John W. Linville wrote:
> Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
> developments and/or issues between drivers and mac80211 or other
> parts of the stack?
Unfortunately I didn't get "sponsorship" to join the summit this year.
Second one (for different reasons) that I'll miss in a row. Hopefully
next time I'll be there.
Have fun! :)
--
Cheers,
Luca.
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Seth Forshee @ 2013-09-09 21:50 UTC (permalink / raw)
To: John W. Linville
Cc: Dan Williams, linux-wireless, johannes, marcel, Samuel Ortiz,
Gustavo Padovan, linux-bluetooth, linux-nfc
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
On Mon, Sep 09, 2013 at 03:23:46PM -0400, John W. Linville wrote:
> Seth, Stanislaw, etc -- anyone want to cover issues dealing with
> supporting wireless in distributions?
Probably best if we can get input from all those present representing
distros. I'm happy to share about what our biggest pain points are in
Ubuntu.
Seth
^ permalink raw reply
* Re: [linux-nfc] Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: Marcel Holtmann @ 2013-09-09 20:48 UTC (permalink / raw)
To: John W. Linville
Cc: Samuel Ortiz, Dan Williams, linux-nfc, linux-wireless,
linux-bluetooth, johannes
In-Reply-To: <20130909192346.GC1955@tuxdriver.com>
Hi John,
>>>> Sorry, forgot to copy linux-bluetooth and linux-nfc...
>>>>
>>>> On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
>>>>> Greetings!
>>>>>
>>>>> This is a reminder that we will have a Linux Wireless Mini-Summit in
>>>>> New Orleans this year on 19-20 September. This will immediately follow
>>>>> LinuxCon and will run concurrently with Linux Plumber's Conference.
>>>>> This event includes Linux developers for wireless LAN (802.11),
>>>>> Bluetooth, and NFC technologies. Both kernel and userland developers
>>>>> are welcomed and heartily encouraged to attend!
>>>>>
>>>>> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>>>>>
>>>>> The link above is a Wiki. We are using it to collect discussion
>>>>> topics and to negotiate agenda/scheduling options for the event.
>>>>> Please go there to record your intent to attend the event and to
>>>>> propopse topics for discussion.
>>>>>
>>>>> Please be aware that in order to attend the event above one must
>>>>> register for either LinuxCon or for Linux Plumbers Conference.
>>>>> Act now, before those events fill-up and close their registrations!
>>>>>
>>>>> We are allotted one "large" room (up to ~80 people "theater style"), and
>>>>> two "small" rooms (up to ~25 people) for this event. Based on history
>>>>> and the numbers of contributors, the larger room will primarily be
>>>>> for the 802.11 discussions and any "plenary" topics while the smaller
>>>>> rooms will be for Bluetooth, NFC, and any "breakout" topics.
>>>>>
>>>>> So...thoughts? Topics to discuss?
>>>
>>> Ping? We're now just 2 weeks away!
>>>
>>> Is our topic list complete? It looks a bit light...
>>>
>>> Anyone have any input on scheduling the topics? Are there any
>>> overlapping LPC sessions that it would make sense to work around?
>>
>> I'm attending though I haven't put my name on the wiki yet.
>>
>> Random thoughts; it doesn't look like any of these are covered in the
>> regular LinuxConf or LPC sessions.
>>
>> 1) State of the Union (maybe by multiple people in the same session per
>> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
>> what's happening in BT or NFC land, or not everyone working on a
>> specific driver may know what new stuff their driver might need to be
>> fixed up for. Maybe 5 minutes or less for things like:
>>
>> * what's under the most active development right now?
>> * upcoming new driver, hardware, and new capabilities
>> * new 802.11 standards
>> * and what's coming up in the next year from the standards orgs
>> * what people will start working on soon
>> * what will 3.13 or 3.14 look like from a wireless perspective?
>> * 11s mesh status?
>> * anything interesting in wpa_supplicant land?
>> * anything new/interesting on the Android front?
>>
>> 2) Bluetooth - update about what's new and what's coming up in Bluez
>> land, and interaction with kernel 802.11 if any,
>>
>> 3) NFC - update about what's new and what's coming up in NFC land, where
>> it's getting used, what the stack looks like
>>
>> 4) What are users having the most problems with and how these problems
>> be fixed better/more quickly? Are they driver bugs? Are they stack
>> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
>> development processes that's not working as smoothly as it could be?
>
> Thanks, Dan -- those all look like decent discussion points.
> I've added most of the points above to the topic list:
>
> http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
>
> Now, we need a few volunteers...
>
> Gustavo, can you do a session on Bluetooth developments?
>
> Samuel, can you cover NFC?
I can do the Bluetooth part and I am just volunteering Samuel for NFC ;)
Regards
Marcel
_______________________________________________
Linux-nfc mailing list
Linux-nfc@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nfc
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September
From: John W. Linville @ 2013-09-09 19:23 UTC (permalink / raw)
To: Dan Williams
Cc: linux-wireless, johannes, marcel, Samuel Ortiz, Gustavo Padovan,
linux-bluetooth, linux-nfc
In-Reply-To: <1378397092.3580.21.camel@dcbw.foobar.com>
On Thu, Sep 05, 2013 at 11:04:52AM -0500, Dan Williams wrote:
> On Thu, 2013-09-05 at 09:39 -0400, John W. Linville wrote:
> > On Thu, Aug 08, 2013 at 03:04:29PM -0400, John W. Linville wrote:
> > > Sorry, forgot to copy linux-bluetooth and linux-nfc...
> > >
> > > On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> > > > Greetings!
> > > >
> > > > This is a reminder that we will have a Linux Wireless Mini-Summit in
> > > > New Orleans this year on 19-20 September. This will immediately follow
> > > > LinuxCon and will run concurrently with Linux Plumber's Conference.
> > > > This event includes Linux developers for wireless LAN (802.11),
> > > > Bluetooth, and NFC technologies. Both kernel and userland developers
> > > > are welcomed and heartily encouraged to attend!
> > > >
> > > > http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> > > >
> > > > The link above is a Wiki. We are using it to collect discussion
> > > > topics and to negotiate agenda/scheduling options for the event.
> > > > Please go there to record your intent to attend the event and to
> > > > propopse topics for discussion.
> > > >
> > > > Please be aware that in order to attend the event above one must
> > > > register for either LinuxCon or for Linux Plumbers Conference.
> > > > Act now, before those events fill-up and close their registrations!
> > > >
> > > > We are allotted one "large" room (up to ~80 people "theater style"), and
> > > > two "small" rooms (up to ~25 people) for this event. Based on history
> > > > and the numbers of contributors, the larger room will primarily be
> > > > for the 802.11 discussions and any "plenary" topics while the smaller
> > > > rooms will be for Bluetooth, NFC, and any "breakout" topics.
> > > >
> > > > So...thoughts? Topics to discuss?
> >
> > Ping? We're now just 2 weeks away!
> >
> > Is our topic list complete? It looks a bit light...
> >
> > Anyone have any input on scheduling the topics? Are there any
> > overlapping LPC sessions that it would make sense to work around?
>
> I'm attending though I haven't put my name on the wiki yet.
>
> Random thoughts; it doesn't look like any of these are covered in the
> regular LinuxConf or LPC sessions.
>
> 1) State of the Union (maybe by multiple people in the same session per
> their expertise), since perhaps not everyone doing eg 802.11 stuff knows
> what's happening in BT or NFC land, or not everyone working on a
> specific driver may know what new stuff their driver might need to be
> fixed up for. Maybe 5 minutes or less for things like:
>
> * what's under the most active development right now?
> * upcoming new driver, hardware, and new capabilities
> * new 802.11 standards
> * and what's coming up in the next year from the standards orgs
> * what people will start working on soon
> * what will 3.13 or 3.14 look like from a wireless perspective?
> * 11s mesh status?
> * anything interesting in wpa_supplicant land?
> * anything new/interesting on the Android front?
>
> 2) Bluetooth - update about what's new and what's coming up in Bluez
> land, and interaction with kernel 802.11 if any,
>
> 3) NFC - update about what's new and what's coming up in NFC land, where
> it's getting used, what the stack looks like
>
> 4) What are users having the most problems with and how these problems
> be fixed better/more quickly? Are they driver bugs? Are they stack
> bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
> development processes that's not working as smoothly as it could be?
Thanks, Dan -- those all look like decent discussion points.
I've added most of the points above to the topic list:
http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
Now, we need a few volunteers...
Gustavo, can you do a session on Bluetooth developments?
Samuel, can you cover NFC?
Jouni, would you mind doing your usual update on the standards
activities? Also, is there anything new/interesting to report on
wpa_suppliant and/or hostapd?
Johannes, would you cover your vision for mac80211 for the next year
or so? Anything in progress now that needs to be discussed?
Who should cover any Android topics?
Arend, Kalle, Johannes, Luca, etc -- anyone want to talk about driver
developments and/or issues between drivers and mac80211 or other
parts of the stack?
Seth, Stanislaw, etc -- anyone want to cover issues dealing with
supporting wireless in distributions?
Dan Williams, Daniel Wagner, etc -- anyone got some user stories
to share?
Dan Williams, Marcel Holtmann -- how about a NM vs. ConnMan death
match?? :-)
Let's get this stuff fleshed-out!
John
P.S. Has everyone added themselves to the attendee list? It looks
a little short...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 1/1] obexd: Use documented values in org.bluez.obex.Message1 Type property
From: Christian Fetzer @ 2013-09-09 16:30 UTC (permalink / raw)
To: linux-bluetooth
From: Christian Fetzer <christian.fetzer@bmw-carit.de>
This updates the values that are presented in the Type property to use
the values from the documentation ("email", "sms-gsm", "sms-cdma", "mms").
The existing code directly used the values as received in the messages
listing object ("EMAIL", "SMS_GSM", "SMS_CDMA", "MMS").
---
obexd/client/map.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/obexd/client/map.c b/obexd/client/map.c
index f0dcf72..95f0334 100644
--- a/obexd/client/map.c
+++ b/obexd/client/map.c
@@ -894,7 +894,17 @@ static void parse_type(struct map_msg *msg, const char *value)
return;
g_free(msg->type);
- msg->type = g_strdup(value);
+
+ if (strcasecmp(value, "SMS_GSM") == 0)
+ msg->type = g_strdup("sms-gsm");
+ else if (strcasecmp(value, "SMS_CDMA") == 0)
+ msg->type = g_strdup("sms-cdma");
+ else if (strcasecmp(value, "EMAIL") == 0)
+ msg->type = g_strdup("email");
+ else if (strcasecmp(value, "MMS") == 0)
+ msg->type = g_strdup("mms");
+ else
+ msg->type = NULL;
g_dbus_emit_property_changed(conn, msg->path,
MAP_MSG_INTERFACE, "Type");
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH 2/3] sco-tester: Introduce adapter features
From: Johan Hedberg @ 2013-09-09 15:03 UTC (permalink / raw)
To: Frédéric DALLEAU; +Cc: linux-bluetooth
In-Reply-To: <522DC4FD.1010601@linux.intel.com>
Hi Frederic,
On Mon, Sep 09, 2013, Frédéric DALLEAU wrote:
> >First of all, you should use "false" here instead of "0" (and same for
> >true vs 1 later).
> >
> >Secondly, whenever you want to manipulate some parameter of a test case
> >it should not be done in the main function like that but instead you
> >should have it as part of the test case data (struct sco_client_data)
> >and create a separate instance for each test case.
> >
> >I do realize that the initial sco-tester didn't get this right (having
> >disable_sco in struct test_data instead of struct sco_client_data), but
> >it'd be good to get this fixed before adding any new test cases.
>
> The problem is that the adapter feature has to be defined far before
> the test is started.
The sco_client structs are static ones and therefore available when the
tester starts, so I'm not sure what the issue is.
> Another problem is that sco_client_data is test dependant, eg. each
> test can implement sco_client_data differently. In this case,
> adapter_features could simply be undefined! This is already the case
> in the first tests which do not use struct sco_client_data at all
> (test_socket).
>
> IMHO We do not want that. adapter_features must be defined explictly
> before each test. This is mandatory.
>
> In future I'm also thinking to implement some adapter "behavior".
> For example : one test could be : try connect, emulator must accept,
> and expected result is success. then try connect, emulator must
> refuse, and result is expected to be connection refused.
>
> My suggestion would be really different from yours :
> I would write a big table with the elements of test_sco.
>
> struct test {
> char *name;
> struct adapter_features *features;
> struct adapter_behavior *behavior; /* If needed */
> void (*test_cb)(struct test *test, void *data);
> void *user_data; /* sco_client_data*/
> int expected_result;
> } tests [] = {...};
>
> while (test[i].name) {
> test_sco(test[i].name, test[i].test_cb, ...);
> i++;
> }
>
> Let me know what you think.
I wasn't trying to suggest something new but just describe what the
other end-to-end testers under tools/ do. Take a look at e.g.
l2cap-tester or mgmt-tester (which has the most extensive list of test
cases). Neither one of those has needed anything similar to what you're
proposing and if we go ahead and adopt a new model for sco-tester then
all the testers should follow it.
If you feel like the adapter properties have to be somewhere "higher up"
than sco_client_data (which they really don't have to be) one option is
to move it to the test_data and simply have separate macros for defining
test cases for different types of controllers, just like mgmt-tester
does with test_bredrle(), test_bredr() and test_le().
Johan
^ permalink raw reply
* [PATCH BlueZ 8/8] gdbus/client: Use g_dbus_add_properties_watch to track properties
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This make the handling much simpler and avoids duplicates of the same
match rule.
---
gdbus/client.c | 135 ++++++++++++++++++++++++---------------------------------
1 file changed, 56 insertions(+), 79 deletions(-)
diff --git a/gdbus/client.c b/gdbus/client.c
index 01d7d02..7bffdad 100644
--- a/gdbus/client.c
+++ b/gdbus/client.c
@@ -67,7 +67,7 @@ struct GDBusProxy {
char *obj_path;
char *interface;
GHashTable *prop_list;
- char *match_rule;
+ guint watch;
GDBusPropertyFunction prop_func;
void *prop_data;
GDBusProxyFunction removed_func;
@@ -358,6 +358,52 @@ static GDBusProxy *proxy_lookup(GDBusClient *client, const char *path,
return NULL;
}
+static gboolean properties_changed(DBusConnection *conn, DBusMessage *msg,
+ void *user_data)
+{
+ GDBusProxy *proxy = user_data;
+ GDBusClient *client = proxy->client;
+ DBusMessageIter iter, entry;
+ const char *interface;
+
+ if (dbus_message_iter_init(msg, &iter) == FALSE)
+ return TRUE;
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
+ return TRUE;
+
+ dbus_message_iter_get_basic(&iter, &interface);
+ dbus_message_iter_next(&iter);
+
+ update_properties(proxy, &iter, TRUE);
+
+ dbus_message_iter_next(&iter);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_ARRAY)
+ return TRUE;
+
+ dbus_message_iter_recurse(&iter, &entry);
+
+ while (dbus_message_iter_get_arg_type(&entry) == DBUS_TYPE_STRING) {
+ const char *name;
+
+ dbus_message_iter_get_basic(&entry, &name);
+
+ g_hash_table_remove(proxy->prop_list, name);
+
+ if (proxy->prop_func)
+ proxy->prop_func(proxy, name, NULL, proxy->prop_data);
+
+ if (client->property_changed)
+ client->property_changed(proxy, name, NULL,
+ client->user_data);
+
+ dbus_message_iter_next(&entry);
+ }
+
+ return TRUE;
+}
+
static GDBusProxy *proxy_new(GDBusClient *client, const char *path,
const char *interface)
{
@@ -373,14 +419,12 @@ static GDBusProxy *proxy_new(GDBusClient *client, const char *path,
proxy->prop_list = g_hash_table_new_full(g_str_hash, g_str_equal,
NULL, prop_entry_free);
-
- proxy->match_rule = g_strdup_printf("type='signal',"
- "sender='%s',path='%s',interface='%s',"
- "member='PropertiesChanged',arg0='%s'",
- client->service_name, proxy->obj_path,
- DBUS_INTERFACE_PROPERTIES, proxy->interface);
-
- modify_match(client->dbus_conn, "AddMatch", proxy->match_rule);
+ proxy->watch = g_dbus_add_properties_watch(client->dbus_conn,
+ client->service_name,
+ proxy->obj_path,
+ proxy->interface,
+ properties_changed,
+ proxy, NULL);
return g_dbus_proxy_ref(proxy);
}
@@ -395,11 +439,7 @@ static void proxy_free(gpointer data)
if (client->proxy_removed)
client->proxy_removed(proxy, client->user_data);
- modify_match(client->dbus_conn, "RemoveMatch",
- proxy->match_rule);
-
- g_free(proxy->match_rule);
- proxy->match_rule = NULL;
+ g_dbus_remove_watch(client->dbus_conn, proxy->watch);
g_hash_table_remove_all(proxy->prop_list);
@@ -800,64 +840,6 @@ static void refresh_properties(GDBusClient *client)
}
}
-static void properties_changed(GDBusClient *client, const char *path,
- DBusMessage *msg)
-{
- GDBusProxy *proxy = NULL;
- DBusMessageIter iter, entry;
- const char *interface;
- GList *list;
-
- if (dbus_message_iter_init(msg, &iter) == FALSE)
- return;
-
- if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRING)
- return;
-
- dbus_message_iter_get_basic(&iter, &interface);
- dbus_message_iter_next(&iter);
-
- for (list = g_list_first(client->proxy_list); list;
- list = g_list_next(list)) {
- GDBusProxy *data = list->data;
-
- if (g_str_equal(data->interface, interface) == TRUE &&
- g_str_equal(data->obj_path, path) == TRUE) {
- proxy = data;
- break;
- }
- }
-
- if (proxy == NULL)
- return;
-
- update_properties(proxy, &iter, TRUE);
-
- dbus_message_iter_next(&iter);
-
- if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_ARRAY)
- return;
-
- dbus_message_iter_recurse(&iter, &entry);
-
- while (dbus_message_iter_get_arg_type(&entry) == DBUS_TYPE_STRING) {
- const char *name;
-
- dbus_message_iter_get_basic(&entry, &name);
-
- g_hash_table_remove(proxy->prop_list, name);
-
- if (proxy->prop_func)
- proxy->prop_func(proxy, name, NULL, proxy->prop_data);
-
- if (client->property_changed)
- client->property_changed(proxy, name, NULL,
- client->user_data);
-
- dbus_message_iter_next(&entry);
- }
-}
-
static void parse_properties(GDBusClient *client, const char *path,
const char *interface, DBusMessageIter *iter)
{
@@ -1095,7 +1077,7 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
DBusMessage *message, void *user_data)
{
GDBusClient *client = user_data;
- const char *sender, *path, *interface, *member;
+ const char *sender, *path, *interface;
if (dbus_message_get_type(message) != DBUS_MESSAGE_TYPE_SIGNAL)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
@@ -1106,17 +1088,12 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
path = dbus_message_get_path(message);
interface = dbus_message_get_interface(message);
- member = dbus_message_get_member(message);
if (g_str_has_prefix(path, client->base_path) == FALSE)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- if (g_str_equal(interface, DBUS_INTERFACE_PROPERTIES) == TRUE) {
- if (g_str_equal(member, "PropertiesChanged") == TRUE)
- properties_changed(client, path, message);
-
+ if (g_str_equal(interface, DBUS_INTERFACE_PROPERTIES) == TRUE)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
if (client->signal_func)
client->signal_func(connection, message, client->signal_data);
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 7/8] gdbus/client: Use g_dbus_add_signal_watch to track signals
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This make the handling much simpler and avoids duplicates of the same
match rule.
---
gdbus/client.c | 73 +++++++++++++++++++++++++++++-----------------------------
1 file changed, 37 insertions(+), 36 deletions(-)
diff --git a/gdbus/client.c b/gdbus/client.c
index 7a14d7e..01d7d02 100644
--- a/gdbus/client.c
+++ b/gdbus/client.c
@@ -25,6 +25,7 @@
#include <config.h>
#endif
+#include <stdio.h>
#include <glib.h>
#include <dbus/dbus.h>
@@ -32,12 +33,18 @@
#define METHOD_CALL_TIMEOUT (300 * 1000)
+#ifndef DBUS_INTERFACE_OBJECT_MANAGER
+#define DBUS_INTERFACE_OBJECT_MANAGER DBUS_INTERFACE_DBUS ".ObjectManager"
+#endif
+
struct GDBusClient {
int ref_count;
DBusConnection *dbus_conn;
char *service_name;
char *base_path;
guint watch;
+ guint added_watch;
+ guint removed_watch;
GPtrArray *match_rules;
DBusPendingCall *pending_call;
DBusPendingCall *get_objects_call;
@@ -908,16 +915,18 @@ static void parse_interfaces(GDBusClient *client, const char *path,
}
}
-static void interfaces_added(GDBusClient *client, DBusMessage *msg)
+static gboolean interfaces_added(DBusConnection *conn, DBusMessage *msg,
+ void *user_data)
{
+ GDBusClient *client = user_data;
DBusMessageIter iter;
const char *path;
if (dbus_message_iter_init(msg, &iter) == FALSE)
- return;
+ return TRUE;
if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_OBJECT_PATH)
- return;
+ return TRUE;
dbus_message_iter_get_basic(&iter, &path);
dbus_message_iter_next(&iter);
@@ -927,24 +936,28 @@ static void interfaces_added(GDBusClient *client, DBusMessage *msg)
parse_interfaces(client, path, &iter);
g_dbus_client_unref(client);
+
+ return TRUE;
}
-static void interfaces_removed(GDBusClient *client, DBusMessage *msg)
+static gboolean interfaces_removed(DBusConnection *conn, DBusMessage *msg,
+ void *user_data)
{
+ GDBusClient *client = user_data;
DBusMessageIter iter, entry;
const char *path;
if (dbus_message_iter_init(msg, &iter) == FALSE)
- return;
+ return TRUE;
if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_OBJECT_PATH)
- return;
+ return TRUE;
dbus_message_iter_get_basic(&iter, &path);
dbus_message_iter_next(&iter);
if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_ARRAY)
- return;
+ return TRUE;
dbus_message_iter_recurse(&iter, &entry);
@@ -959,6 +972,8 @@ static void interfaces_removed(GDBusClient *client, DBusMessage *msg)
}
g_dbus_client_unref(client);
+
+ return TRUE;
}
static void parse_managed_objects(GDBusClient *client, DBusMessage *msg)
@@ -1093,24 +1108,6 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
interface = dbus_message_get_interface(message);
member = dbus_message_get_member(message);
- if (g_str_equal(path, "/") == TRUE) {
- if (g_str_equal(interface, DBUS_INTERFACE_DBUS
- ".ObjectManager") == FALSE)
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
-
- if (g_str_equal(member, "InterfacesAdded") == TRUE) {
- interfaces_added(client, message);
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
- if (g_str_equal(member, "InterfacesRemoved") == TRUE) {
- interfaces_removed(client, message);
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
if (g_str_has_prefix(path, client->base_path) == FALSE)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
@@ -1150,23 +1147,25 @@ GDBusClient *g_dbus_client_new(DBusConnection *connection,
client->service_name = g_strdup(service);
client->base_path = g_strdup(path);
- client->match_rules = g_ptr_array_sized_new(3);
+ client->match_rules = g_ptr_array_sized_new(1);
g_ptr_array_set_free_func(client->match_rules, g_free);
client->watch = g_dbus_add_service_watch(connection, service,
service_connect,
service_disconnect,
client, NULL);
- g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
- "sender='%s',"
- "path='/',interface='%s.ObjectManager',"
- "member='InterfacesAdded'",
- client->service_name, DBUS_INTERFACE_DBUS));
- g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
- "sender='%s',"
- "path='/',interface='%s.ObjectManager',"
- "member='InterfacesRemoved'",
- client->service_name, DBUS_INTERFACE_DBUS));
+ client->added_watch = g_dbus_add_signal_watch(connection, service,
+ "/",
+ DBUS_INTERFACE_OBJECT_MANAGER,
+ "InterfacesAdded",
+ interfaces_added,
+ client, NULL);
+ client->removed_watch = g_dbus_add_signal_watch(connection, service,
+ "/",
+ DBUS_INTERFACE_OBJECT_MANAGER,
+ "InterfacesRemoved",
+ interfaces_removed,
+ client, NULL);
g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
"sender='%s',path_namespace='%s'",
client->service_name, client->base_path));
@@ -1225,6 +1224,8 @@ void g_dbus_client_unref(GDBusClient *client)
client->disconn_func(client->dbus_conn, client->disconn_data);
g_dbus_remove_watch(client->dbus_conn, client->watch);
+ g_dbus_remove_watch(client->dbus_conn, client->added_watch);
+ g_dbus_remove_watch(client->dbus_conn, client->removed_watch);
dbus_connection_unref(client->dbus_conn);
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 6/8] gdbus/client: Use g_dbus_add_service_watch to track services
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This make the handling much simpler and avoids duplicates of the same
match rule.
---
gdbus/client.c | 173 +++++++++++++--------------------------------------------
1 file changed, 38 insertions(+), 135 deletions(-)
diff --git a/gdbus/client.c b/gdbus/client.c
index 8ebfaad..7a14d7e 100644
--- a/gdbus/client.c
+++ b/gdbus/client.c
@@ -36,8 +36,8 @@ struct GDBusClient {
int ref_count;
DBusConnection *dbus_conn;
char *service_name;
- char *unique_name;
char *base_path;
+ guint watch;
GPtrArray *match_rules;
DBusPendingCall *pending_call;
DBusPendingCall *get_objects_call;
@@ -1051,74 +1051,36 @@ static void get_managed_objects(GDBusClient *client)
dbus_message_unref(msg);
}
-static void get_name_owner_reply(DBusPendingCall *call, void *user_data)
+static void service_connect(DBusConnection *conn, void *user_data)
{
GDBusClient *client = user_data;
- DBusMessage *reply = dbus_pending_call_steal_reply(call);
- DBusError error;
- const char *name;
g_dbus_client_ref(client);
- dbus_error_init(&error);
-
- if (dbus_set_error_from_message(&error, reply) == TRUE) {
- dbus_error_free(&error);
- goto done;
- }
-
- if (dbus_message_get_args(reply, NULL, DBUS_TYPE_STRING, &name,
- DBUS_TYPE_INVALID) == FALSE)
- goto done;
-
- if (client->unique_name == NULL) {
- client->unique_name = g_strdup(name);
-
- if (client->connect_func)
- client->connect_func(client->dbus_conn,
- client->connect_data);
-
- get_managed_objects(client);
- }
-
-done:
- dbus_message_unref(reply);
+ if (client->connect_func)
+ client->connect_func(conn, client->connect_data);
- dbus_pending_call_unref(client->pending_call);
- client->pending_call = NULL;
+ get_managed_objects(client);
g_dbus_client_unref(client);
}
-static void get_name_owner(GDBusClient *client, const char *name)
+static void service_disconnect(DBusConnection *conn, void *user_data)
{
- DBusMessage *msg;
-
- msg = dbus_message_new_method_call(DBUS_SERVICE_DBUS, DBUS_PATH_DBUS,
- DBUS_INTERFACE_DBUS, "GetNameOwner");
- if (msg == NULL)
- return;
-
- dbus_message_append_args(msg, DBUS_TYPE_STRING, &name,
- DBUS_TYPE_INVALID);
-
- if (g_dbus_send_message_with_reply(client->dbus_conn, msg,
- &client->pending_call, -1) == FALSE) {
- dbus_message_unref(msg);
- return;
- }
+ GDBusClient *client = user_data;
- dbus_pending_call_set_notify(client->pending_call,
- get_name_owner_reply, client, NULL);
+ g_list_free_full(client->proxy_list, proxy_free);
+ client->proxy_list = NULL;
- dbus_message_unref(msg);
+ if (client->disconn_func)
+ client->disconn_func(conn, client->disconn_data);
}
static DBusHandlerResult message_filter(DBusConnection *connection,
DBusMessage *message, void *user_data)
{
GDBusClient *client = user_data;
- const char *sender;
+ const char *sender, *path, *interface, *member;
if (dbus_message_get_type(message) != DBUS_MESSAGE_TYPE_SIGNAL)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
@@ -1127,98 +1089,41 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
if (sender == NULL)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- if (g_str_equal(sender, DBUS_SERVICE_DBUS) == TRUE) {
- const char *interface, *member;
- const char *name, *old, *new;
+ path = dbus_message_get_path(message);
+ interface = dbus_message_get_interface(message);
+ member = dbus_message_get_member(message);
- interface = dbus_message_get_interface(message);
-
- if (g_str_equal(interface, DBUS_INTERFACE_DBUS) == FALSE)
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
-
- member = dbus_message_get_member(message);
-
- if (g_str_equal(member, "NameOwnerChanged") == FALSE)
+ if (g_str_equal(path, "/") == TRUE) {
+ if (g_str_equal(interface, DBUS_INTERFACE_DBUS
+ ".ObjectManager") == FALSE)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- if (dbus_message_get_args(message, NULL,
- DBUS_TYPE_STRING, &name,
- DBUS_TYPE_STRING, &old,
- DBUS_TYPE_STRING, &new,
- DBUS_TYPE_INVALID) == FALSE)
+ if (g_str_equal(member, "InterfacesAdded") == TRUE) {
+ interfaces_added(client, message);
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+ }
- if (g_str_equal(name, client->service_name) == FALSE)
+ if (g_str_equal(member, "InterfacesRemoved") == TRUE) {
+ interfaces_removed(client, message);
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
-
- if (*new == '\0' && client->unique_name != NULL &&
- g_str_equal(old, client->unique_name) == TRUE) {
-
- g_list_free_full(client->proxy_list, proxy_free);
- client->proxy_list = NULL;
-
- if (client->disconn_func)
- client->disconn_func(client->dbus_conn,
- client->disconn_data);
-
- g_free(client->unique_name);
- client->unique_name = NULL;
- } else if (*old == '\0' && client->unique_name == NULL) {
- client->unique_name = g_strdup(new);
-
- if (client->connect_func)
- client->connect_func(client->dbus_conn,
- client->connect_data);
-
- get_managed_objects(client);
}
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
- if (client->unique_name == NULL)
+ if (g_str_has_prefix(path, client->base_path) == FALSE)
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- if (g_str_equal(sender, client->unique_name) == TRUE) {
- const char *path, *interface, *member;
-
- path = dbus_message_get_path(message);
- interface = dbus_message_get_interface(message);
- member = dbus_message_get_member(message);
-
- if (g_str_equal(path, "/") == TRUE) {
- if (g_str_equal(interface, DBUS_INTERFACE_DBUS
- ".ObjectManager") == FALSE)
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
-
- if (g_str_equal(member, "InterfacesAdded") == TRUE) {
- interfaces_added(client, message);
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
- if (g_str_equal(member, "InterfacesRemoved") == TRUE) {
- interfaces_removed(client, message);
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
+ if (g_str_equal(interface, DBUS_INTERFACE_PROPERTIES) == TRUE) {
+ if (g_str_equal(member, "PropertiesChanged") == TRUE)
+ properties_changed(client, path, message);
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
- if (g_str_has_prefix(path, client->base_path) == FALSE)
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
-
- if (g_str_equal(interface, DBUS_INTERFACE_PROPERTIES) == TRUE) {
- if (g_str_equal(member, "PropertiesChanged") == TRUE)
- properties_changed(client, path, message);
-
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
- }
-
- if (client->signal_func)
- client->signal_func(client->dbus_conn,
- message, client->signal_data);
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
+ if (client->signal_func)
+ client->signal_func(connection, message, client->signal_data);
+
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
@@ -1245,16 +1150,13 @@ GDBusClient *g_dbus_client_new(DBusConnection *connection,
client->service_name = g_strdup(service);
client->base_path = g_strdup(path);
- get_name_owner(client, client->service_name);
-
- client->match_rules = g_ptr_array_sized_new(4);
+ client->match_rules = g_ptr_array_sized_new(3);
g_ptr_array_set_free_func(client->match_rules, g_free);
- g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
- "sender='%s',path='%s',interface='%s',"
- "member='NameOwnerChanged',arg0='%s'",
- DBUS_SERVICE_DBUS, DBUS_PATH_DBUS,
- DBUS_INTERFACE_DBUS, client->service_name));
+ client->watch = g_dbus_add_service_watch(connection, service,
+ service_connect,
+ service_disconnect,
+ client, NULL);
g_ptr_array_add(client->match_rules, g_strdup_printf("type='signal',"
"sender='%s',"
"path='/',interface='%s.ObjectManager',"
@@ -1322,10 +1224,11 @@ void g_dbus_client_unref(GDBusClient *client)
if (client->disconn_func)
client->disconn_func(client->dbus_conn, client->disconn_data);
+ g_dbus_remove_watch(client->dbus_conn, client->watch);
+
dbus_connection_unref(client->dbus_conn);
g_free(client->service_name);
- g_free(client->unique_name);
g_free(client->base_path);
g_free(client);
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 5/8] gdbus/watch: Fix crash when disconnecting from D-Bus
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When disconnecting from D-Bus a message could be recieved with no sender:
Invalid read of size 1
at 0x4A09EE1: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C386B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4065D6: message_filter (watch.c:529)
by 0x3B0700F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x4052E7: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x4038C5: client_proxy_removed (test-gdbus-client.c:902)
by 0x3B03C6B566: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C6B6E5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x0 is not stack'd, malloc'd or (recently) free'd
---
gdbus/watch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index a918535..1532795 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -519,6 +519,8 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
dbus_message_get_args(message, NULL, DBUS_TYPE_STRING, &arg, DBUS_TYPE_INVALID);
/* Sender is always the owner */
+ if (sender == NULL)
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
for (current = listeners; current != NULL; current = current->next) {
data = current->data;
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 4/8] gdbus/watch: Fix aborting when removing D-Bus filter
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In case of filter_data having a watch to a service name it may call
dbus_connection_remove_filter twice causing libdbus to abort:
process 24723: Attempt to remove filter function 0x4063e0 user data (nil), but no such filter has been added
To fix this the code will now only attempt to call
dbus_connection_remove_filter once in filter_data_free which is the
counterpart of filter_data_get where dbus_connection_add_filter is called.
---
gdbus/watch.c | 25 ++++++++-----------------
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index d334580..a918535 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -281,6 +281,11 @@ static void filter_data_free(struct filter_data *data)
{
GSList *l;
+ /* Remove filter if there are no listeners left for the connection */
+ if (filter_data_find(data->connection) == NULL)
+ dbus_connection_remove_filter(data->connection, message_filter,
+ NULL);
+
for (l = data->callbacks; l != NULL; l = l->next)
g_free(l->data);
@@ -360,8 +365,6 @@ static void service_data_free(struct service_data *data)
static gboolean filter_data_remove_callback(struct filter_data *data,
struct filter_callback *cb)
{
- DBusConnection *connection;
-
data->callbacks = g_slist_remove(data->callbacks, cb);
data->processed = g_slist_remove(data->processed, cb);
@@ -385,16 +388,8 @@ static gboolean filter_data_remove_callback(struct filter_data *data,
if (data->registered && !remove_match(data))
return FALSE;
- connection = dbus_connection_ref(data->connection);
listeners = g_slist_remove(listeners, data);
-
- /* Remove filter if there are no listeners left for the connection */
- if (filter_data_find(connection) == NULL)
- dbus_connection_remove_filter(connection, message_filter,
- NULL);
-
filter_data_free(data);
- dbus_connection_unref(connection);
return TRUE;
}
@@ -563,6 +558,9 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
current);
}
+ if (delete_listener == NULL)
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+
for (current = delete_listener; current != NULL;
current = delete_listener->next) {
GSList *l = current->data;
@@ -581,11 +579,6 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
g_slist_free(delete_listener);
- /* Remove filter if there are no listeners left for the connection */
- if (filter_data_find(connection) == NULL)
- dbus_connection_remove_filter(connection, message_filter,
- NULL);
-
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
@@ -814,6 +807,4 @@ void g_dbus_remove_all_watches(DBusConnection *connection)
listeners = g_slist_remove(listeners, data);
filter_data_call_and_free(data);
}
-
- dbus_connection_remove_filter(connection, message_filter, NULL);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 3/8] gdbus/watch: Fix crash when g_dbus_remove_watch is called from connect callback
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
at 0x40570C: update_service (watch.c:601)
by 0x40584B: service_reply (watch.c:627)
by 0x3B0700C511: ??? (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x3B0700F740: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4)
by 0x405167: message_dispatch (mainloop.c:76)
by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
Address 0x4c58a30 is 32 bytes inside a block of size 56 free'd
at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x3B03C4D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
by 0x406102: filter_data_remove_callback (watch.c:378)
by 0x405FC0: g_dbus_remove_watch (watch.c:798)
by 0x40A22B: g_dbus_client_unref (client.c:1227)
by 0x40570B: update_service (watch.c:599)
by 0x40584B: service_reply (watch.c:627)
---
gdbus/watch.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index 9e4f994..d334580 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -593,12 +593,16 @@ static gboolean update_service(void *user_data)
{
struct service_data *data = user_data;
struct filter_callback *cb = data->callback;
+ DBusConnection *conn;
update_name_cache(data->name, data->owner);
+ conn = dbus_connection_ref(data->conn);
+ service_data_free(cb->data);
+
if (cb->conn_func)
- cb->conn_func(data->conn, cb->user_data);
+ cb->conn_func(conn, cb->user_data);
- service_data_free(data);
+ dbus_connection_unref(conn);
return FALSE;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 2/8] unit: Add gdbus/client_force_disconnect
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1378738179-21047-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This tests if watches created using g_dbus_proxy_set_removed_watch works
when the service disconnects from the bus.
---
unit/test-gdbus-client.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
index 30b0ce3..685729a 100644
--- a/unit/test-gdbus-client.c
+++ b/unit/test-gdbus-client.c
@@ -29,6 +29,7 @@
#include <gdbus.h>
#define SERVICE_NAME "org.bluez.unit.test-gdbus-client"
+#define SERVICE_NAME1 "org.bluez.unit.test-gdbus-client1"
#define SERVICE_PATH "/org/bluez/unit/test_gdbus_client"
struct context {
@@ -903,6 +904,61 @@ static void client_proxy_removed(void)
destroy_context(context);
}
+static void proxy_force_disconnect(GDBusProxy *proxy, void *user_data)
+{
+ struct context *context = user_data;
+ DBusConnection *conn = context->data;
+
+ if (g_test_verbose())
+ g_print("proxy %s found\n",
+ g_dbus_proxy_get_interface(proxy));
+
+ g_assert(g_dbus_proxy_set_removed_watch(proxy, proxy_removed, context));
+
+ context->timeout_source = g_timeout_add_seconds(2, timeout_test,
+ context);
+
+ dbus_connection_flush(conn);
+ dbus_connection_close(conn);
+ context->data = NULL;
+}
+
+static void client_force_disconnect(void)
+{
+ struct context *context = create_context();
+ DBusConnection *conn;
+ static const GDBusPropertyTable string_properties[] = {
+ { "String", "s", get_string, set_string, string_exists },
+ { },
+ };
+
+ if (context == NULL)
+ return;
+
+ conn = g_dbus_setup_private(DBUS_BUS_SESSION, SERVICE_NAME1, NULL);
+ g_assert(conn != NULL);
+
+ /* Avoid D-Bus library calling _exit() before next test finishes. */
+ dbus_connection_set_exit_on_disconnect(conn, FALSE);
+ g_dbus_attach_object_manager(conn);
+ context->data = conn;
+
+ g_dbus_register_interface(conn, SERVICE_PATH, SERVICE_NAME1,
+ methods, signals, string_properties,
+ context, NULL);
+
+ context->dbus_client = g_dbus_client_new(context->dbus_conn,
+ SERVICE_NAME1, SERVICE_PATH);
+
+ g_dbus_client_set_proxy_handlers(context->dbus_client,
+ proxy_force_disconnect, NULL, NULL,
+ context);
+
+ g_main_loop_run(context->main_loop);
+
+ destroy_context(context);
+}
+
int main(int argc, char *argv[])
{
g_test_init(&argc, &argv, NULL);
@@ -937,5 +993,8 @@ int main(int argc, char *argv[])
g_test_add_func("/gdbus/client_proxy_removed", client_proxy_removed);
+ g_test_add_func("/gdbus/client_force_disconnect",
+ client_force_disconnect);
+
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH BlueZ 1/8] unit: Add gdbus/client_proxy_removed
From: Luiz Augusto von Dentz @ 2013-09-09 14:49 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This tests if watches created using g_dbus_proxy_set_removed_watch works
when the interface is removed.
---
unit/test-gdbus-client.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
index 488d4ec..30b0ce3 100644
--- a/unit/test-gdbus-client.c
+++ b/unit/test-gdbus-client.c
@@ -848,6 +848,61 @@ static void client_check_order(void)
destroy_context(context);
}
+static void proxy_removed(GDBusProxy *proxy, void *user_data)
+{
+ struct context *context = user_data;
+
+ if (g_test_verbose())
+ g_print("proxy removed\n");
+
+ g_main_loop_quit(context->main_loop);
+}
+
+static void proxy_set_removed(GDBusProxy *proxy, void *user_data)
+{
+ struct context *context = user_data;
+
+ if (g_test_verbose())
+ g_print("proxy %s found\n",
+ g_dbus_proxy_get_interface(proxy));
+
+ g_assert(g_dbus_proxy_set_removed_watch(proxy, proxy_removed, context));
+
+ context->timeout_source = g_timeout_add_seconds(2, timeout_test,
+ context);
+
+ g_dbus_unregister_interface(context->dbus_conn, SERVICE_PATH,
+ SERVICE_NAME);
+}
+
+static void client_proxy_removed(void)
+{
+ struct context *context = create_context();
+ static const GDBusPropertyTable string_properties[] = {
+ { "String", "s", get_string, set_string, string_exists },
+ { },
+ };
+
+ if (context == NULL)
+ return;
+
+ g_dbus_register_interface(context->dbus_conn,
+ SERVICE_PATH, SERVICE_NAME,
+ methods, signals, string_properties,
+ context, NULL);
+
+ context->dbus_client = g_dbus_client_new(context->dbus_conn,
+ SERVICE_NAME, SERVICE_PATH);
+
+ g_dbus_client_set_proxy_handlers(context->dbus_client,
+ proxy_set_removed, NULL, NULL,
+ context);
+
+ g_main_loop_run(context->main_loop);
+
+ destroy_context(context);
+}
+
int main(int argc, char *argv[])
{
g_test_init(&argc, &argv, NULL);
@@ -880,5 +935,7 @@ int main(int argc, char *argv[])
g_test_add_func("/gdbus/client_check_order", client_check_order);
+ g_test_add_func("/gdbus/client_proxy_removed", client_proxy_removed);
+
return g_test_run();
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH BlueZ 00/10 v3] Fix message order
From: Luiz Augusto von Dentz @ 2013-09-09 14:40 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1378207279-14557-1-git-send-email-luiz.dentz@gmail.com>
Hi,
On Tue, Sep 3, 2013 at 2:21 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> s set fixes a couple of issues introduced with the use of ObjectManager due
> the processing of signals on idle to group changes, this has been causing
> issues with external components such as ofono and pulseaudio that sometimes
> receives connections from devices objects that have pending signals thus
> cannot be properly processed or have to be assumed paired and with certain
> UUIDs which is not ideal.
>
> v2: Fixes some commit messages as suggested by Lucas Demarchi, in addition to
> that rework flush mechanism to honor the order of the pending signals and make
> it work with any connection.
>
> v3: Add comments regarding the use of dbus_connection_send to prevent recursive
> calls to g_dbus_flush.
>
> Luiz Augusto von Dentz (10):
> build: Fix not rebuilding bluetoothd if gdbus changes
> unit: Add gdbus/client_check_order
> gdbus: Fix sending ObjectManager/Properties signals out of order
> gdbus: Add g_dbus_send_message_with_reply
> gdbus: Avoid calling dbus_connection_send*
> gdbus: Fix emitting PropertiesChanged twice
> core: Make use of g_dbus_send_message_with_reply
> neard: Make use of g_dbus_send_message_with_reply
> audio/media: Make use of g_dbus_send_message_with_reply
> obexd: Make use of g_dbus_send_message*
>
> Makefile.am | 2 +-
> gdbus/client.c | 14 ++--
> gdbus/gdbus.h | 3 +
> gdbus/object.c | 176 ++++++++++++++++++++++++------------------
> obexd/plugins/bluetooth.c | 2 +-
> obexd/plugins/pcsuite.c | 5 +-
> obexd/plugins/syncevolution.c | 6 +-
> obexd/src/manager.c | 3 +-
> plugins/neard.c | 2 +-
> profiles/audio/media.c | 2 +-
> src/agent.c | 12 +--
> src/profile.c | 4 +-
> unit/test-gdbus-client.c | 71 +++++++++++++++++
> 13 files changed, 200 insertions(+), 102 deletions(-)
>
> --
> 1.8.3.1
I went ahead and pushed this upstream.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 2/3] sco-tester: Introduce adapter features
From: Frédéric DALLEAU @ 2013-09-09 12:54 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20130909083356.GC29399@x220.p-661hnu-f1>
Hi Johan,
> First of all, you should use "false" here instead of "0" (and same for
> true vs 1 later).
>
> Secondly, whenever you want to manipulate some parameter of a test case
> it should not be done in the main function like that but instead you
> should have it as part of the test case data (struct sco_client_data)
> and create a separate instance for each test case.
>
> I do realize that the initial sco-tester didn't get this right (having
> disable_sco in struct test_data instead of struct sco_client_data), but
> it'd be good to get this fixed before adding any new test cases.
The problem is that the adapter feature has to be defined far before the
test is started.
Another problem is that sco_client_data is test dependant, eg. each
test can implement sco_client_data differently. In this case,
adapter_features could simply be undefined! This is already the case in
the first tests which do not use struct sco_client_data at all
(test_socket).
IMHO We do not want that. adapter_features must be defined explictly
before each test. This is mandatory.
In future I'm also thinking to implement some adapter "behavior". For
example : one test could be : try connect, emulator must accept, and
expected result is success. then try connect, emulator must refuse, and
result is expected to be connection refused.
My suggestion would be really different from yours :
I would write a big table with the elements of test_sco.
struct test {
char *name;
struct adapter_features *features;
struct adapter_behavior *behavior; /* If needed */
void (*test_cb)(struct test *test, void *data);
void *user_data; /* sco_client_data*/
int expected_result;
} tests [] = {...};
while (test[i].name) {
test_sco(test[i].name, test[i].test_cb, ...);
i++;
}
Let me know what you think.
Regards,
Frédéric
^ permalink raw reply
* Re: [RFC 0/1] MAP Notification API
From: Luiz Augusto von Dentz @ 2013-09-09 12:19 UTC (permalink / raw)
To: Christian Fetzer; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZKk0m=Wp3zuNfLpTFCnGy1PE0LTOFQq8uNoEGARVV+TAg@mail.gmail.com>
Hi Christian,
On Wed, Aug 7, 2013 at 12:15 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Christian,
>
> On Fri, Jul 12, 2013 at 11:23 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Christian,
>>
>> On Fri, Jul 12, 2013 at 11:02 AM, Christian Fetzer
>> <christian.fetzer@oss.bmw-carit.de> wrote:
>>> Hi Luiz,
>>>
>>> On 07/10/2013 10:56 AM, Luiz Augusto von Dentz wrote:
>>>> Hi Christian,
>>>>
>>>> On Mon, Jun 24, 2013 at 10:56 AM, Christian Fetzer
>>>> <christian.fetzer@oss.bmw-carit.de> wrote:
>>>>> From: Christian Fetzer <christian.fetzer@bmw-carit.de>
>>>>>
>>>>> Now that the MAP MNS support is progressing, I'd like to start the discussion
>>>>> on how the MAP event reports should be signaled in the D-Bus API.
>>>>>
>>>>> I've listed therefore the 9 different event types and the parameters that we
>>>>> get from the remote device, together with a proposal on how the API could look
>>>>> like.
>>>>>
>>>>>
>>>>> Prerequisite:
>>>>>
>>>>> The current existing MAP client relies on the fact that the application tracks
>>>>> the folder a message belongs to. Since notifications can be received for any
>>>>> folder, it would make sense to remove this restriction and provide a 'Folder'
>>>>> property for the Message interface. This is needed for the NewMessage,
>>>>> MessageDeleted, and MessageShift event.
>>>>>
>>>>>
>>>>> Events:
>>>>>
>>>>> NewMessage(handle, folder, msg_type):
>>>>> - New messages can be signaled by registering a corresponding Message
>>>>> interface, that would be announced using the ObjectManager.
>>>>> - Since we do not get any meta data, it would make sense to implicitly query
>>>>> this information using GetMessagesListing with MaxListCount=1.
>>>>> That way, the application would not have to query this data explicitly and
>>>>> we would not expose an empty message with no properties set.
>>>>
>>>> Sound good to me.
>>>>
>>>>> DeliverySuccess,SendingSuccess,DeliveryFailure,
>>>>> SendingFailure(handle, folder, msg_type):
>>>>> - This events are only relevant when sending messages (PushMessage).
>>>>> Therefore, I'd suggest to register the Message interface already in
>>>>> PushMessage for the outgoing message and add a SendingStatus property
>>>>> when we receive this events.
>>>>
>>>> I wonder how this is actually implemented, is there a NewMessage event
>>>> when using PushMessage? If yes does it indicates Sent flag or we
>>>> should listen to this event and notified when it is sent, anyway the
>>>> event doesn't give us detailed error so perhaps we could just set
>>>> Status to error or something like that, adding another status would be
>>>> confusing IMO.
>>>>
>>>
>>> According to the spec, it should be implemented like this:
>>> - The client sends the PushMessage request
>>> - In the response, the server sets the OBEX Name parameter of the last
>>> response packet to the handle that this message gets on the server.
>>> - The server will try to send the message and will inform the client
>>> about the status using above notifications. This usually takes some
>>> seconds (or longer, especially when the reception is bad).
>>>
>>> MCE MSE
>>> | --- PushMessage_Req ---------------> |
>>> | <-- PushMessage_Res(Name=handle) --- |
>>> ...
>>> MSE tries to deliver message
>>> ...
>>> | <-- Status event report ------------ |
>>>
>>> Note that the type of notification also depend on the network.
>>> Sometimes, the operator accepts all messages (and you only get
>>> SendingSuccess notifications). In error cases, you receive a SMS,
>>> saying that the delivery failed. In this case you get a NewMessage
>>> notification (but only plain text, no status codes).
>>
>> So if I understand you correctly the NewMessage is only generated when
>> the message is sent, in that case we should probably create the
>> message object with the response as you said.
>>
>>> The idea was, to then register the new message's D-Bus interface
>>> as soon as we have transfered the message to the phone (when we received
>>> the handle in PushMessage_Res). Later, when we receive
>>> a status notification, we update a property in the message.
>>> The Status property could be reused as well here if you don't want a
>>> dedicated property. Does that make sense for you?
>>
>> The Status should be used as the status of the message not only for
>> receiving status, for direction we have the Sent property. We should
>> always try to keep the API as simple as possible so there is less risk
>> we need to break APIs, adding those latter is possible but I don't
>> think it will the case here.
>>
>>> I've done some tests with a BB Z10 to verify that the described
>>> behavior is correct. (see below for a trace)
>>>
>>>>> MemoryFull, MemoryAvailable():
>>>>> - Add MemoryAvailable property in MessageAccess interface.
>>>>
>>>> It is not very clear how we would use this? Do you actually have any
>>>> stack generating these events? Anyway we could also handle it
>>>> internally and do not send any data upon receiving MemoryFull, anyway
>>>> lets think about it latter.
>>>>
>>>
>>> I don't think we have to 'handle' anything in case of MemoryFull.
>>> This is just an indication for the application/UI that you will
>>> not be able to receive / send any new messages.
>>
>> Lets concentrate on the other events we can come back to this latter.
>
> Anything coming from your side anything soon or are you waiting some feedback?
We are still lacking the processing of the events in
obexd/client/map.c:map_handle_notification, are you going to send the
patches to add it?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 2/3] sco-tester: Introduce adapter features
From: Johan Hedberg @ 2013-09-09 8:33 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376062977-1497-2-git-send-email-frederic.dalleau@linux.intel.com>
Hi Frederic,
On Fri, Aug 09, 2013, Frédéric Dalleau wrote:
> +struct adapter_features {
> + bool disable_esco;
> +};
> +
> struct test_data {
> const void *test_data;
> struct mgmt *mgmt;
> @@ -50,7 +54,7 @@ struct test_data {
> struct hciemu *hciemu;
> enum hciemu_type hciemu_type;
> unsigned int io_id;
> - bool disable_esco;
> + struct adapter_features features;
> };
>
> struct sco_client_data {
> @@ -164,7 +168,7 @@ static void read_index_list_callback(uint8_t status, uint16_t length,
>
> tester_print("New hciemu instance created");
>
> - if (data->disable_esco) {
> + if (data->features.disable_esco) {
> uint8_t *features;
>
> tester_print("Disabling eSCO packet type support");
> @@ -211,7 +215,7 @@ static void test_data_free(void *test_data)
> free(data);
> }
>
> -#define test_sco_full(name, data, setup, func, _disable_esco) \
> +#define test_sco(name, data, setup, func, feat) \
> do { \
> struct test_data *user; \
> user = malloc(sizeof(struct test_data)); \
> @@ -220,17 +224,12 @@ static void test_data_free(void *test_data)
> user->hciemu_type = HCIEMU_TYPE_BREDRLE; \
> user->io_id = 0; \
> user->test_data = data; \
> - user->disable_esco = _disable_esco; \
> + user->features = feat; \
> tester_add_full(name, data, \
> test_pre_setup, setup, func, NULL, \
> test_post_teardown, 2, user, test_data_free); \
> } while (0)
>
> -#define test_sco(name, data, setup, func) \
> - test_sco_full(name, data, setup, func, false)
> -
> -#define test_sco_11(name, data, setup, func) \
> - test_sco_full(name, data, setup, func, true)
>
> static const struct sco_client_data connect_success = {
> .expect_err = 0
> @@ -575,31 +574,37 @@ end:
>
> int main(int argc, char *argv[])
> {
> + static struct adapter_features features;
> +
> tester_init(&argc, &argv);
>
> + features.disable_esco = 0;
First of all, you should use "false" here instead of "0" (and same for
true vs 1 later).
Secondly, whenever you want to manipulate some parameter of a test case
it should not be done in the main function like that but instead you
should have it as part of the test case data (struct sco_client_data)
and create a separate instance for each test case.
I do realize that the initial sco-tester didn't get this right (having
disable_sco in struct test_data instead of struct sco_client_data), but
it'd be good to get this fixed before adding any new test cases.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] sco-tester: Update ECONNABORTED to EOPNOTSUPP
From: Johan Hedberg @ 2013-09-09 8:29 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1376062977-1497-1-git-send-email-frederic.dalleau@linux.intel.com>
Hi Frederic,
On Fri, Aug 09, 2013, Frédéric Dalleau wrote:
> Kernel interface has evolved in between.
> ---
> tools/sco-tester.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I've applied and pushed this patch, but there are a couple of details in
the other ones that I'd like to get fixed before pushing.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Only schedule raw queue when user channel is active
From: Johan Hedberg @ 2013-09-09 8:23 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378256918-50836-2-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Tue, Sep 03, 2013, Marcel Holtmann wrote:
> When the user channel is set and an user application has full control
> over the device, do not bother trying to schedule any queues except
> the raw queue.
>
> This is an optimization since with user channel, only the raw queue
> is in use.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Johan
^ permalink raw reply
* Can't initialize a Bluetooth antenna.
From: atar @ 2013-09-09 7:08 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi there!!
When I try to use the hciconfig command to initialized my Bluetooth
antenna like the command:
hciconfig hci0 up OR hciconfig hci0 reset
it emits an error message saying:
Can't init device hci0: Connection timed out (110).
dmesg reports the following errors messages:
[ 15.084017] Bluetooth: hci0 command tx timeout
[ 17.611516] input: ACPI Virtual Keyboard Device as
/devices/virtual/input/input5
[ 32.826814] Bluetooth: RFCOMM TTY layer initialized
[ 32.828142] Bluetooth: RFCOMM socket layer initialized
[ 32.829376] Bluetooth: RFCOMM ver 1.11
[ 32.869417] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 32.870701] Bluetooth: BNEP filters: protocol multicast
[ 33.422622] lp0: using parport0 (interrupt-driven).
[ 33.433318] ppdev: user-space parallel port driver
[ 33.982250] atl2 0000:01:00.0: irq 43 for MSI/MSI-X
[ 33.982474] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 38.136034] usb 2-1: reset full-speed USB device number 2 using uhci_hcd
[ 38.286042] btusb 2-1:1.0: no reset_resume for driver btusb?
[ 38.286048] btusb 2-1:1.1: no reset_resume for driver btusb?
[ 66.706329] fuse init (API version 7.17)
and the 'bluez-simple-agent' command emits the following error messages:
Traceback (most recent call last):
File "/usr/bin/bluez-simple-agent", line 104, in <module>
path = manager.DefaultAdapter()
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in
__call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.bluez.Error.NoSuchAdapter: No such
adapter
Has anyone here an idea what's going on?
NOTE: the system is a Wheezy Debian system.
Thanks in advance!!
atar.
^ permalink raw reply
* [PATCH bluez] bnep: don't error() if kernel lacks bnep module
From: David Herrmann @ 2013-09-06 14:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann, Johan Hedberg, David Herrmann
If a user disables bnep kernel support, they normally do that on purpose.
It's misleading to print an error during module-startup in this situation.
Therefore, only print a hint that bnep-support is missing if
EPROTONOSUPPORT is returned by the kernel.
Furthermore, allow modules to forward ENOSYS as error to bluetoothd core
to handle it as "module is not compatible with system setup" instead of an
error. ENOSYS is commonly used to signal "missing kernel infrastructure"
so it seems appropriate here.
---
profiles/network/common.c | 7 ++++++-
profiles/network/manager.c | 17 ++++++++++++++---
src/plugin.c | 11 +++++++++--
3 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/profiles/network/common.c b/profiles/network/common.c
index e069892..17bff30 100644
--- a/profiles/network/common.c
+++ b/profiles/network/common.c
@@ -110,8 +110,13 @@ int bnep_init(void)
if (ctl < 0) {
int err = -errno;
- error("Failed to open control socket: %s (%d)",
+
+ if (err == -EPROTONOSUPPORT)
+ info("kernel lacks bnep-protocol support");
+ else
+ error("Failed to open control socket: %s (%d)",
strerror(-err), -err);
+
return err;
}
diff --git a/profiles/network/manager.c b/profiles/network/manager.c
index 03b1b3d..7697766 100644
--- a/profiles/network/manager.c
+++ b/profiles/network/manager.c
@@ -25,6 +25,7 @@
#include <config.h>
#endif
+#include <errno.h>
#include <stdbool.h>
#include <bluetooth/bluetooth.h>
@@ -169,11 +170,21 @@ static struct btd_profile nap_profile = {
static int network_init(void)
{
+ int r;
+
read_config(CONFIGDIR "/network.conf");
- if (bnep_init()) {
- error("Can't init bnep module");
- return -1;
+ r = bnep_init();
+ if (r) {
+ if (r == -EPROTONOSUPPORT) {
+ info("bnep module not available, disabling plugin");
+ r = -ENOSYS;
+ } else {
+ error("Can't init bnep module");
+ r = -1;
+ }
+
+ return r;
}
/*
diff --git a/src/plugin.c b/src/plugin.c
index 51c98bc..396c8af 100644
--- a/src/plugin.c
+++ b/src/plugin.c
@@ -119,6 +119,7 @@ gboolean plugin_init(const char *enable, const char *disable)
const char *file;
char **cli_disabled, **cli_enabled;
unsigned int i;
+ int r;
/* Make a call to BtIO API so its symbols got resolved before the
* plugins are loaded. */
@@ -196,8 +197,14 @@ start:
for (list = plugins; list; list = list->next) {
struct bluetooth_plugin *plugin = list->data;
- if (plugin->desc->init() < 0) {
- error("Failed to init %s plugin", plugin->desc->name);
+ r = plugin->desc->init();
+ if (r < 0) {
+ if (r == -ENOSYS)
+ info("System does not support %s plugin",
+ plugin->desc->name);
+ else
+ error("Failed to init %s plugin",
+ plugin->desc->name);
continue;
}
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Use GFP_KERNEL when cloning SKB in a workqueue
From: Johan Hedberg @ 2013-09-06 10:41 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1378257067-52933-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Tue, Sep 03, 2013, Marcel Holtmann wrote:
> There is no need to use GFP_ATOMIC with skb_clone() when the code is
> executed in a workqueue.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/hci_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox