[PATCH 18/56] build: Load the right modules depending on the BlueZ version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 26, 2013 at 10:13 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Thu, 2013-07-25 at 00:08 -0300, jprvita at gmail.com wrote:
>> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org>
>>
>> Support for BlueZ 4 is built only when bluez.pc is present on the target
>> system, and that is a big hint that we should load the BlueZ 4 modules.
>> On all other cases we can try to load the BlueZ 5 modules.
>> ---
>>  configure.ac             | 3 +++
>>  src/daemon/default.pa.in | 9 ++++++++-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index a63cc82..d23e1aa 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1008,6 +1008,9 @@ AS_IF([test "x$enable_bluez5" = "xyes" && test "x$HAVE_BLUEZ_5" != "x1"],
>>  AC_SUBST(HAVE_BLUEZ_5)
>>  AM_CONDITIONAL([HAVE_BLUEZ_5], [test "x$HAVE_BLUEZ_5" = x1])
>>
>> +AS_IF([test "x$HAVE_BLUEZ_4" = "x1" || test "x$HAVE_BLUEZ_5" = "x1"], HAVE_BLUEZ=1)
>> +AC_SUBST(HAVE_BLUEZ)
>> +
>>  #### UDEV support (optional) ####
>>
>>  AC_ARG_ENABLE([udev],
>> diff --git a/src/daemon/default.pa.in b/src/daemon/default.pa.in
>> index 19dd8a6..4130c7a 100755
>> --- a/src/daemon/default.pa.in
>> +++ b/src/daemon/default.pa.in
>> @@ -84,16 +84,23 @@ load-module module-detect
>>  load-module module-jackdbus-detect channels=2
>>  .fail
>>  .endif
>> +ifelse(@HAVE_BLUEZ@, 1, [dnl
>>
>> -ifelse(@HAVE_BLUEZ_4@, 1, [dnl
>>  ### Automatically load driver modules for Bluetooth hardware
>>  .ifexists module-bluetooth-policy at PA_SOEXT@
>>  load-module module-bluetooth-policy
>>  .endif
>> +ifelse(@HAVE_BLUEZ_4@, 1, [dnl
>>
>>  .ifexists module-bluez4-discover at PA_SOEXT@
>>  load-module module-bluez4-discover
>>  .endif
>> +], [dnl
>> +
>> +.ifexists module-bluez5-discover at PA_SOEXT@
>> +load-module module-bluez5-discover
>> +.endif
>> +])dnl
>>  ])dnl
>>
>>  ifelse(@HAVE_AF_UNIX@, 1, [dnl
>
> As discussed in IRC, we should load module-bluetooth-discover in
> default.pa instead of the version specific modules.
>

I think I managed to find a solution that will make everyone happy:
after changing the prefix of the BlueZ 4 support to pa_bluez4_ and
with a few more changes, like separating the paths of the
org.bluez.MediaEndpoint objects, the BlueZ 4 and BlueZ 5 modules can
run side-by-side. So basically module-bluetooth-discover can load each
module-bluez?-discovery.so it finds installed. To check for installed
modules I'm using access() and the pathname is contructed using
lt_dlgetsearchpath() in the exact same way ".ifexists" in default.pa
does. So "load module-bluetooth-discover" is equivalent to the
following piece of default.pa:

.ifexists module-bluez5-discover.so
load-module module-bluez5-discover
.endif

.ifexists module-bluez4-discover.so
load-module module-bluez4-discover
.endif

I think that's both suitable for developers, to ease testing both
BlueZ versions, and distros that want to provide an upgrade path from
BlueZ 4 to BlueZ 5. If only one version of BlueZ support is installed
then module-bluetooth-discover will only try to load that module,
avoiding having unused code loaded in memory. The load of
module-bluetooth-discover can also be avoided if it impacts load time
in some use cases by changing module-bluetooth-discover to the desired
module-bluez?-discover in default.pa.

And last but not least, at some point we may want to kick out this
wrapping mechanism in favor of supporting BlueZ 5 only by default.

-- 
Jo?o Paulo Rechi Vita
http://about.me/jprvita


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux