Variable arguments to Inquiry and PeriodicInquiry D-BUS methods

PATCH In review Johan Hedberg 3 participants 8 messages Nov 8, 2005 Bluetooth drivers

lore

Share & tools

lore

Johan Hedberg

author

2005-11-08 13:43 UTC #0 lore raw

PATCH 1/1 Variable arguments to Inquiry and PeriodicInquiry D-BUS methods

Hi,

Here's a patch which allows Inquiry and PeriodicInquiry to be called with two possible sets of parameters. We can't unfortunately get (at least very easily) the same flexibility that you can get with e.g. command line options because there are no "labels" for the D-BUS parameters. So, the solution I went for was that either you provide only the essential parameters (the ones that don't have a sane default value), or then you provide all parameters.

The possible ways of calling the methods after applying this patch are:

Inquiry()
Inquiry(byte: length, byte: num_rsp, uint32: lap) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period,

		byte: num_rsp, uint32: lap)

With dbus-test you can test this with e.g.
./dbus-test Inquiry 8 100 0x9e8b33

Then, I'd like to start some discussion about the interface for setting default values for certain parameters. I'd suggest to use a similar interface that we currently have for the properties where there are only two methods ("Set" and "Get") and strings are used to identify the parameter which should be operated on. I think it would be good to have each module under the device path (e.g. "Controller", "PAN", etc.) implement this interface. You would then do something like:

Object: /org/bluez/Device/hci0/Controller
Interface: org.bluez.Defaults
Method: Set("LAP", 0x9e8b00)

Object: /org/bluez/Device/hci0/Controller
Interface: org.bluez.Defaults
Method: Set("role", "slave")

Object: /org/bluez/Device/hci0/RFCOMM
Interface: org.bluez.Defaults
Method: Set("authenticate", True)

Does this sound like a sensible way to do it?

Johan

Index: hcid/dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.3

dbus-test +16 ~~-11~~

diff -u -r1.3 dbus-test
@@ -182,12 +182,12 @@
 
         # Device.Controller methods
         elif self.cmd == 'Inquiry':
-            if len(self.cmd_args) != 2:
-                length, maxrsp = (10, 100)
-            else:
-                length, maxrsp = self.cmd_args
             try:
-                self.ctl.Inquiry(dbus.Byte(length), dbus.Byte(maxrsp))
+                if len(self.cmd_args) != 3:
+                    self.ctl.Inquiry()
+                else:
+                    length, maxrsp, lap = self.cmd_args
+                    self.ctl.Inquiry(dbus.Byte(length), dbus.Byte(maxrsp), dbus.UInt32(long(lap, 0)))
             except dbus.DBusException, e:
                 print 'Sending %s failed: %s' % (self.cmd, e)
                 sys.exit(1)

@@ -216,13 +216,18 @@
             self.exit_events.append('RemoteName')
 
         elif self.cmd == 'PeriodicInquiry':
-            if len(self.cmd_args) != 3:
-                length, min, max = (6, 20, 60)
-            else:
-                length, min, max = self.cmd_args
-            self.listen = True
             try:
-                self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                if len(self.cmd_args) < 3:
+                    length, min, max = (6, 20, 60)
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                elif len(self.cmd_args) == 3:
+                    length, min, max = self.cmd_args
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                else:
+                    length, min, max, nrsp, lap = self.cmd_args
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max),
+                            dbus.Byte(nrsp), dbus.UInt32(long(lap, 0)))
+                self.listen = True
             except dbus.DBusException, e:
                 print 'Sending %s failed: %s' % (self.cmd, e)
                 sys.exit(1)

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

dbus.c +44 ~~-27~~

116 lines not on this page · raw message

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

dbus.h +10 -1

diff -u -r1.15 dbus.h
@@ -164,6 +164,12 @@
 #define DEV_GET_PROPERTY_SIGNATURE		DBUS_TYPE_STRING_AS_STRING \
 						__END_SIG__
 
+#define HCI_PERIODIC_INQ_EXT_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING \
+							DBUS_TYPE_UINT16_AS_STRING \
+							DBUS_TYPE_UINT16_AS_STRING \
+							DBUS_TYPE_BYTE_AS_STRING \
+							DBUS_TYPE_UINT32_AS_STRING \
+							__END_SIG__
 
 #define HCI_PERIODIC_INQ_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING \
 							DBUS_TYPE_UINT16_AS_STRING \

@@ -172,8 +178,11 @@
 
 #define HCI_CANCEL_PERIODIC_INQ_SIGNATURE		__END_SIG__
 
-#define HCI_INQ_SIGNATURE				DBUS_TYPE_BYTE_AS_STRING \
+#define HCI_INQ_SIGNATURE				__END_SIG__
+
+#define HCI_INQ_EXT_SIGNATURE				DBUS_TYPE_BYTE_AS_STRING \
 							DBUS_TYPE_BYTE_AS_STRING \
+							DBUS_TYPE_UINT32_AS_STRING \
 							__END_SIG__
 
 #define HCI_CANCEL_INQ_SIGNATURE			__END_SIG__

Marcel Holtmann

maintainer

2005-11-08 13:54 UTC #1 lore raw

Hi Johan,

Quoted 8 lines

Here's a patch which allows Inquiry and PeriodicInquiry to be called with two possible sets of parameters. We can't unfortunately get (at least very easily) the same flexibility that you can get with e.g. command line options because there are no "labels" for the D-BUS parameters. So, the solution I went for was that either you provide only the essential parameters (the ones that don't have a sane default value), or then you provide all parameters.

Quoted 7 lines

The possible ways of calling the methods after applying this patch are:
Inquiry()
Inquiry(byte: length, byte: num_rsp, uint32: lap) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period,
		byte: num_rsp, uint32: lap)

please swap the lap and num_rsp (call it num_responses btw.) and make the num_responses also optional. It is more usual that you will specify a different lap instead of num_responses. The reason for this is, because the num_responses value is not really useful anymore. All chips in inquiry mode 1 or 2 tend to send results multiple times and this makes the num_responses value useless. It is only good for devices where the memory storage for inquiry results is limited. Maybe we shouldn't use it at all.

Is it not better to call it access_code instead of lap?

The length parameter should also be in seconds and not the slot timing we get from the baseband.

Quoted 16 lines

Then, I'd like to start some discussion about the interface for setting default values for certain parameters. I'd suggest to use a similar interface that we currently have for the properties where there are only two methods ("Set" and "Get") and strings are used to identify the parameter which should be operated on. I think it would be good to have each module under the device path (e.g. "Controller", "PAN", etc.) implement this interface. You would then do something like:
Object: /org/bluez/Device/hci0/Controller
Interface: org.bluez.Defaults
Method: Set("LAP", 0x9e8b00)
Object: /org/bluez/Device/hci0/Controller
Interface: org.bluez.Defaults
Method: Set("role", "slave")

Quoted 5 lines

Object: /org/bluez/Device/hci0/RFCOMM
Interface: org.bluez.Defaults
Method: Set("authenticate", True)
Does this sound like a sensible way to do it?

I am not unhappy with it at the moment.

Regards

Marcel

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Johan Hedberg

author

2005-11-08 14:30 UTC #2 lore raw

Hi Marcel,

Attached is a new patch with some of your proposed changes (the ones I agree with ;)

Quoted 8 lines · Marcel Holtmann

Quoted 7 lines
The possible ways of calling the methods after applying this patch are:
Inquiry()
Inquiry(byte: length, byte: num_rsp, uint32: lap) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period,
		byte: num_rsp, uint32: lap)

Quoted 8 lines

please swap the lap and num_rsp (call it num_responses btw.) and make the num_responses also optional. It is more usual that you will specify a different lap instead of num_responses. The reason for this is, because the num_responses value is not really useful anymore. All chips in inquiry mode 1 or 2 tend to send results multiple times and this makes the num_responses value useless. It is only good for devices where the memory storage for inquiry results is limited. Maybe we shouldn't use it at all.

I removed the num_responses parameter alltogether. If it's needed we can always allow changing it through the default settings interface in the future.

Quoted 1 line

Is it not better to call it access_code instead of lap?

Maybe. I called it lap since that's what your structs in hci.h and the HCI spec calls it. Note that the terms we use in the code don't have to the same what we put in the (yet to be created) public documentation of the interface.

Quoted 2 lines

The length parameter should also be in seconds and not the slot timing we get from the baseband.

Well, then it would always have to be rounded to the nearest 1.28 sec multiple, so I'm not so sure how useful it would be (and it might be even confusing for the user when the inquiry doesn't last the exact amount of seconds that was given). I've left it unchanged for now. I can send a new patch later specifically for it. If we do change it, should it be an integer or a floating point number?

Johan

Index: hcid/dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.3

dbus-test +16 ~~-11~~

diff -u -r1.3 dbus-test
@@ -182,12 +182,12 @@
 
         # Device.Controller methods
         elif self.cmd == 'Inquiry':
-            if len(self.cmd_args) != 2:
-                length, maxrsp = (10, 100)
-            else:
-                length, maxrsp = self.cmd_args
             try:
-                self.ctl.Inquiry(dbus.Byte(length), dbus.Byte(maxrsp))
+                if len(self.cmd_args) != 2:
+                    self.ctl.Inquiry()
+                else:
+                    length, lap = self.cmd_args
+                    self.ctl.Inquiry(dbus.Byte(length), dbus.UInt32(long(lap, 0)))
             except dbus.DBusException, e:
                 print 'Sending %s failed: %s' % (self.cmd, e)
                 sys.exit(1)

@@ -216,13 +216,18 @@
             self.exit_events.append('RemoteName')
 
         elif self.cmd == 'PeriodicInquiry':
-            if len(self.cmd_args) != 3:
-                length, min, max = (6, 20, 60)
-            else:
-                length, min, max = self.cmd_args
-            self.listen = True
             try:
-                self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                if len(self.cmd_args) < 3:
+                    length, min, max = (6, 20, 60)
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                elif len(self.cmd_args) == 3:
+                    length, min, max = self.cmd_args
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max))
+                else:
+                    length, min, max, lap = self.cmd_args
+                    self.ctl.PeriodicInquiry(dbus.Byte(length), dbus.UInt16(min), dbus.UInt16(max),
+                            dbus.UInt32(long(lap, 0)))
+                self.listen = True
             except dbus.DBusException, e:
                 print 'Sending %s failed: %s' % (self.cmd, e)
                 sys.exit(1)

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

dbus.c +43 ~~-28~~

117 lines not on this page · raw message

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

dbus.h +9 -2

diff -u -r1.15 dbus.h
@@ -164,6 +164,11 @@
 #define DEV_GET_PROPERTY_SIGNATURE		DBUS_TYPE_STRING_AS_STRING \
 						__END_SIG__
 
+#define HCI_PERIODIC_INQ_EXT_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING \
+							DBUS_TYPE_UINT16_AS_STRING \
+							DBUS_TYPE_UINT16_AS_STRING \
+							DBUS_TYPE_UINT32_AS_STRING \
+							__END_SIG__
 
 #define HCI_PERIODIC_INQ_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING \
 							DBUS_TYPE_UINT16_AS_STRING \

@@ -172,8 +177,10 @@
 
 #define HCI_CANCEL_PERIODIC_INQ_SIGNATURE		__END_SIG__
 
-#define HCI_INQ_SIGNATURE				DBUS_TYPE_BYTE_AS_STRING \
-							DBUS_TYPE_BYTE_AS_STRING \
+#define HCI_INQ_SIGNATURE				__END_SIG__
+
+#define HCI_INQ_EXT_SIGNATURE				DBUS_TYPE_BYTE_AS_STRING \
+							DBUS_TYPE_UINT32_AS_STRING \
 							__END_SIG__
 
 #define HCI_CANCEL_INQ_SIGNATURE			__END_SIG__

Claudio Takahasi

2005-11-08 14:45 UTC #3 lore raw

Hi,

The interface for get/set the default values is fine!

Some suggestions/comments...
1. It's better use the same method name used by device configuration. Currently, device configuration uses SetProperty and GetProperty, it should be better rename to Set and Get. Do you agree?

2. Does it make sense add an extra argument(device class) in order to be notified only by device class that the client wants? Maybe this enhancement should be applied when become possible retrieve the Inquiry cache using the new userspace/kernel communication interface.

3. Periodic inquiry is a concurrent task. Currently there isn't verification for PeriodicInquiry requested by more than one client. In this case how it should work?

Regards,
Claudio.

Quoted 7 lines · Johan Hedberg

Hi Marcel,
Attached is a new patch with some of your proposed changes (the ones I agree with ;)
Quoted 1 line · Marcel Holtmann
Quoted 1 line
The possible ways of calling the methods after applying this patch ar=

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
Inquiry()
Inquiry(byte: length, byte: num_rsp, uint32: lap) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period,
            byte: num_rsp, uint32: lap)

Quoted 6 lines

Quoted 6 lines
please swap the lap and num_rsp (call it num_responses btw.) and make the num_responses also optional. It is more usual that you will specify a different lap instead of num_responses. The reason for this is, because the num_responses value is not really useful anymore. All chips in inquiry mode 1 or 2 tend to send results multiple times and this makes the num_responses value useless. It is only good for devices wher=

Quoted 17 lines

Quoted 2 lines
the memory storage for inquiry results is limited. Maybe we shouldn't use it at all.
I removed the num_responses parameter alltogether. If it's needed we can always allow changing it through the default settings interface in the future.
Quoted 1 line
Is it not better to call it access_code instead of lap?
Maybe. I called it lap since that's what your structs in hci.h and the HCI spec calls it. Note that the terms we use in the code don't have to the same what we put in the (yet to be created) public documentation of the interface.
Quoted 2 lines
The length parameter should also be in seconds and not the slot timing we get from the baseband.

Quoted 11 lines

Well, then it would always have to be rounded to the nearest 1.28 sec multiple, so I'm not so sure how useful it would be (and it might be even confusing for the user when the inquiry doesn't last the exact amount of seconds that was given). I've left it unchanged for now. I can send a new patch later specifically for it. If we do change it, should it be an integer or a floating point number?
Johan

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

Marcel Holtmann

maintainer

2005-11-08 15:03 UTC #4 lore raw

Hi Claudio,

Quoted 3 lines

1. It's better use the same method name used by device configuration. Currently, device configuration uses SetProperty and GetProperty, it should be better rename to Set and Get. Do you agree?

is HAL using something similar? If yes, then we should adapt their way.

Quoted 4 lines

2. Does it make sense add an extra argument(device class) in order to be notified only by device class that the client wants? Maybe this enhancement should be applied when become possible retrieve the Inquiry cache using the new userspace/kernel communication interface.

We really need this lifetime monitoring. This shouldn't be an extra parameter, but a general filter setting for inquiry would be a good enhancement. And we can do it all in userspace.

Quoted 3 lines

3. Periodic inquiry is a concurrent task. Currently there isn't verification for PeriodicInquiry requested by more than one client. In this case how it should work?

It should fail with somekind in progress error indication. However the kernel should set the INQUIRY flag is an inquiry is already in progress. I know that this work for normal inquiries, but I never checked that for the periodic inquiry.

Regards

Marcel

Claudio Takahasi

2005-11-08 16:17 UTC #5 lore raw

Hi,

Quoted 7 lines · Marcel Holtmann

Hi Claudio,
Quoted 3 lines
1. It's better use the same method name used by device configuration. Currently, device configuration uses SetProperty and GetProperty, it should be better rename to Set and Get. Do you agree?
is HAL using something similar? If yes, then we should adapt their way.

[Claudio Takahasi]
HAL implements 5 different methods to set device properties. void SetProperty(string key, any value)
void SetPropertyString(string key, string value) void SetPropertyInteger(string key, int32 value) void SetPropertyBoolean(string key, bool value) void SetPropertyDouble(string key, double value)

We don't need use this approach because we are extracting/comparing the message signature before call the function responsible to execute the task. Our design of having the same method name with differents signatures is fine! Regarding the name, it's better use the same method name "SetProperty" or only "Set" for both(device configuration and Controller).

Quoted 10 lines

Quoted 5 lines
2. Does it make sense add an extra argument(device class) in order to be notified only by device class that the client wants? Maybe this enhancement should be applied when become possible retrieve the Inquiry cache using the new userspace/kernel communication interface.
We really need this lifetime monitoring. This shouldn't be an extra parameter, but a general filter setting for inquiry would be a good enhancement. And we can do it all in userspace.

Quoted 8 lines

Quoted 3 lines
3. Periodic inquiry is a concurrent task. Currently there isn't verification for PeriodicInquiry requested by more than one client. In this case how it should work?
It should fail with somekind in progress error indication. However the kernel should set the INQUIRY flag is an inquiry is already in progress. I know that this work for normal inquiries, but I never checked that for the periodic inquiry.

[Claudio Takahasi]
ok. we need check how it is working now and try implement a policy for this case.

Quoted 11 lines

Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Downl=

oad

Quoted 7 lines

it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

Johan Hedberg

author

2005-11-08 17:31 UTC #6 lore raw

Quoted 7 lines · Claudio Takahasi

HAL implements 5 different methods to set device properties. void SetProperty(string key, any value)
void SetPropertyString(string key, string value) void SetPropertyInteger(string key, int32 value) void SetPropertyBoolean(string key, bool value) void SetPropertyDouble(string key, double value)

Quoted 6 lines

We don't need use this approach because we are extracting/comparing the message signature before call the function responsible to execute the task. Our design of having the same method name with differents signatures is fine! Regarding the name, it's better use the same method name "SetProperty" or only "Set" for both(device configuration and Controller).

I think it's a matter of what the interface name is. If the interface is "org.bluez.Device", then "SetProperty" describes the method better than "Set". If the interface is "org.bluez.Defaults" then just "Set" would probably be enough.

Johan

Marcel Holtmann

maintainer

2005-11-08 14:59 UTC #7 lore raw

In reply to Johan Hedberg

Hi Johan,

Quoted 2 lines

Attached is a new patch with some of your proposed changes (the ones I agree with ;)

the patch is in the CVS now (slightly modified).

Quoted 17 lines

Quoted 8 lines
Quoted 7 lines
The possible ways of calling the methods after applying this patch are:
Inquiry()
Inquiry(byte: length, byte: num_rsp, uint32: lap) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period) PeriodicInquiry(byte: length, uint16: min_period, uint16: max_period,
		byte: num_rsp, uint32: lap)
Quoted 8 lines
please swap the lap and num_rsp (call it num_responses btw.) and make the num_responses also optional. It is more usual that you will specify a different lap instead of num_responses. The reason for this is, because the num_responses value is not really useful anymore. All chips in inquiry mode 1 or 2 tend to send results multiple times and this makes the num_responses value useless. It is only good for devices where the memory storage for inquiry results is limited. Maybe we shouldn't use it at all.

Quoted 3 lines

I removed the num_responses parameter alltogether. If it's needed we can always allow changing it through the default settings interface in the future.

and I renamed it back to num_rsp, because it is only internally.

Quoted 6 lines

Quoted 1 line
Is it not better to call it access_code instead of lap?
Maybe. I called it lap since that's what your structs in hci.h and the HCI spec calls it. Note that the terms we use in the code don't have to the same what we put in the (yet to be created) public documentation of the interface.

Inside the code this doesn't matter. However don't be so picky on the structs defined in hci.h. Some of them are over 4 years old and back then sometimes we had no idea what we were doing.

Quoted 9 lines

Quoted 2 lines
The length parameter should also be in seconds and not the slot timing we get from the baseband.
Well, then it would always have to be rounded to the nearest 1.28 sec multiple, so I'm not so sure how useful it would be (and it might be even confusing for the user when the inquiry doesn't last the exact amount of seconds that was given). I've left it unchanged for now. I can send a new patch later specifically for it. If we do change it, should it be an integer or a floating point number?

I don't see it as a big problem, because we will round to next 1.28 sec to make it at least "length" number of seconds. In most cases this will be some microseconds longer, but that doesn't really matter. The API is event driven and so yes, they can't start another inquiry after exactly "length" number seconds, but they periodic inquiry should used for this kind of tasks anyhow.

Regards

Marcel