Set D-BUS signal paths according to local device

PATCH In review Johan Hedberg 3 participants 4 messages Oct 13, 2005 Bluetooth drivers

lore

Share & tools

lore

Johan Hedberg

author

2005-10-13 17:20 UTC #0 lore raw

PATCH 1/1 Set D-BUS signal paths according to local device

Hi,

The attached patch sets the object path of D-BUS signals according to the local device id, e.g. /org/bluez/Manager/hci0/Controller. It also removes the local address arguments from those signals.

Johan

Index: hcid/dbus.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.c,v
retrieving revision 1.23

dbus.c +49 ~~-19~~

diff -u -r1.23 dbus.c
@@ -338,23 +338,29 @@
 
 void hcid_dbus_inquiry_start(bdaddr_t *local)
 {
-	DBusMessage *message;
+	DBusMessage *message = NULL;
+	char path[MAX_PATH_LENGTH];
 	char *local_addr;
 	bdaddr_t tmp;
+	int id;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal(BLUEZ_HCI_PATH,
+	id = hci_devid(local_addr);
+	if (id < 0) {
+		syslog(LOG_ERR, "No matching device id for %s", local_addr);
+		goto failed;
+	}
+
+	snprintf(path, sizeof(path), "%s/hci%d/%s", MANAGER_PATH, id, BLUEZ_HCI);
+
+	message = dbus_message_new_signal(path,
 				BLUEZ_HCI_INTERFACE, BLUEZ_HCI_INQ_START);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry start message");
 		goto failed;
 	}
 
-	dbus_message_append_args(message,
-					DBUS_TYPE_STRING, &local_addr,
-					DBUS_TYPE_INVALID);
-
 	if (dbus_connection_send(connection, message, NULL) == FALSE) {
 		syslog(LOG_ERR, "Can't send D-BUS inquiry start message");
 		goto failed;

@@ -372,23 +378,29 @@
 
 void hcid_dbus_inquiry_complete(bdaddr_t *local)
 {
-	DBusMessage *message;
+	DBusMessage *message = NULL;
+	char path[MAX_PATH_LENGTH];
 	char *local_addr;
 	bdaddr_t tmp;
+	int id;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal(BLUEZ_HCI_PATH,
+	id = hci_devid(local_addr);
+	if (id < 0) {
+		syslog(LOG_ERR, "No matching device id for %s", local_addr);
+		goto failed;
+	}
+
+	snprintf(path, sizeof(path), "%s/hci%d/%s", MANAGER_PATH, id, BLUEZ_HCI);
+
+	message = dbus_message_new_signal(path,
 				BLUEZ_HCI_INTERFACE, BLUEZ_HCI_INQ_COMPLETE);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry complete message");
 		goto failed;
 	}
 
-	dbus_message_append_args(message,
-					DBUS_TYPE_STRING, &local_addr,
-					DBUS_TYPE_INVALID);
-
 	if (dbus_connection_send(connection, message, NULL) == FALSE) {
 		syslog(LOG_ERR, "Can't send D-BUS inquiry complete message");
 		goto failed;

@@ -406,16 +418,26 @@
 
 void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class, int8_t rssi)
 {
-	DBusMessage *message;
+	DBusMessage *message = NULL;
+	char path[MAX_PATH_LENGTH];
 	char *local_addr, *peer_addr;
 	dbus_uint32_t tmp_class = class;
 	dbus_int32_t tmp_rssi = rssi;
 	bdaddr_t tmp;
+	int id;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal(BLUEZ_HCI_PATH,
+	id = hci_devid(local_addr);
+	if (id < 0) {
+		syslog(LOG_ERR, "No matching device id for %s", local_addr);
+		goto failed;
+	}
+
+	snprintf(path, sizeof(path), "%s/hci%d/%s", MANAGER_PATH, id, BLUEZ_HCI);
+
+	message = dbus_message_new_signal(path,
 				BLUEZ_HCI_INTERFACE, BLUEZ_HCI_INQ_RESULT);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry result message");

@@ -423,7 +445,6 @@
 	}
 
 	dbus_message_append_args(message,
-					DBUS_TYPE_STRING, &local_addr,
 					DBUS_TYPE_STRING, &peer_addr,
 					DBUS_TYPE_UINT32, &tmp_class,
 					DBUS_TYPE_INT32, &tmp_rssi,

@@ -447,14 +468,24 @@
 
 void hcid_dbus_remote_name(bdaddr_t *local, bdaddr_t *peer, char *name)
 {
-	DBusMessage *message;
+	DBusMessage *message = NULL;
+	char path[MAX_PATH_LENGTH];
 	char *local_addr, *peer_addr;
 	bdaddr_t tmp;
+	int id;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal(BLUEZ_HCI_PATH,
+	id = hci_devid(local_addr);
+	if (id < 0) {
+		syslog(LOG_ERR, "No matching device id for %s", local_addr);
+		goto failed;
+	}
+
+	snprintf(path, sizeof(path), "%s/hci%d/%s", MANAGER_PATH, id, BLUEZ_HCI);
+
+	message = dbus_message_new_signal(path,
 				BLUEZ_HCI_INTERFACE, BLUEZ_HCI_REMOTE_NAME);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS remote name message");

@@ -462,7 +493,6 @@
 	}
 
 	dbus_message_append_args(message,
-					DBUS_TYPE_STRING, &local_addr,
 					DBUS_TYPE_STRING, &peer_addr,
 					DBUS_TYPE_STRING, &name,
 					DBUS_TYPE_INVALID);

@@ -1314,7 +1344,7 @@
 	struct hci_dbus_data *dbus_data = data;
 	int i;
 	int dev_id = -1;
-	int sk;
+	int sk = -1;
 
 	if (dbus_data->id == DEFAULT_DEVICE_PATH_ID) {
 		if ((dev_id = hci_get_route(NULL)) < 0) {

Claudio Takahasi

2005-10-13 17:36 UTC #1 lore raw

Hi Johan,

I didn't analized all the patch content, but I guess it's possible change the signature of the functions passing the dev id instead of receive the BT address and convert it.

What do you think?

Regards,
Claudio

Quoted 11 lines · Johan Hedberg

Hi,
The attached patch sets the object path of D-BUS signals according to the local device id, e.g. /org/bluez/Manager/hci0/Controller. It also removes the local address arguments from those signals.
Johan

--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]

Johan Hedberg

author

2005-10-13 18:02 UTC #2 lore raw

Quoted 5 lines · Claudio Takahasi

I didn't analized all the patch content, but I guess it's possible change the signature of the functions passing the dev id instead of receive the BT address and convert it.
What do you think?

Yes, that would also be one possibility. However, it requires some changes to security.c (where those functions are being called from). Also, if we decide to start using the device address (instead of the id) in the object paths, there's no point in changing the function parameters. Maybe Marcel has an opinion about this?

Johan

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-10-13 22:51 UTC #3 lore raw

Hi Johan,

Quoted 11 lines

Quoted 5 lines
I didn't analized all the patch content, but I guess it's possible change the signature of the functions passing the dev id instead of receive the BT address and convert it.
What do you think?
Yes, that would also be one possibility. However, it requires some changes to security.c (where those functions are being called from). Also, if we decide to start using the device address (instead of the id) in the object paths, there's no point in changing the function parameters. Maybe Marcel has an opinion about this?

I applied your patch to get it started. However for the final solution we should send around a string inside the hcid API that will maybe "hci0" or also an alias. For example you can rename Ethernet interfaces and at some point I like to rename Bluetooth HCI interfaces, too. Internally it will still use an id number, but that is only inside the kernel.

Regards

Marcel