[PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hi,

I am posting this patch series to better decouple `bluetoothd` daemon
and `libbluetooth`, as mentioned in the subject.

I am introducing this change to make new BlueZ more granular.
This will allow more control on which components are actually selected
to build.

Major use case for this change is fixing circular dependencies when
bootstrapping new builds where the whole build root is to be recreated
(e.g. Yocto Project).
In these scenarios, to have Bluetooth support enabled in Python,
`libbluetooth` is required at build time to be present but the direct
chain of dependencies would require a Python installation available,
thus introducing circular dependency.
Separating the library and header files from the rest allows build
systems to break the dependency loop.

`--enable-bluetoothd` flag is added to the `configure` script and
it is keeping the same behavior as other flags.

Francesco Giancane (3):
  configure.ac: introduce `--enable-bluetoothd` flag
  Makefile.am: build `bluetoothd` if enabled
  README: document `--enable-bluetoothd` flag

 Makefile.am  |  8 ++++++++
 README       | 14 ++++++++++++++
 configure.ac |  4 ++++
 3 files changed, 26 insertions(+)

-- 
2.49.0.windows.1

[PATCH BlueZ 1/3] configure.ac: introduce `--enable-bluetoothd` flag

[Francesco Giancane]

Add an extra `configure.ac` flag to individually control `bluetoothd`
compilation.
---
 configure.ac | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/configure.ac b/configure.ac
index 955908621..a6eef93bb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -154,6 +154,10 @@ AC_ARG_ENABLE(library, AS_HELP_STRING([--enable-library],
 		[install Bluetooth library]), [enable_library=${enableval}])
 AM_CONDITIONAL(LIBRARY, test "${enable_library}" = "yes")
 
+AC_ARG_ENABLE(bluetoothd, AS_HELP_STRING([--enable-bluetoothd],
+		[install bluetoothd daemon]), [enable_bluetoothd=${enableval}])
+AM_CONDITIONAL(BLUETOOTHD, test "${enable_bluetoothd}" = "yes")
+
 AC_ARG_ENABLE(test, AS_HELP_STRING([--enable-test],
 		[enable test/example scripts]), [enable_test=${enableval}])
 AM_CONDITIONAL(TEST, test "${enable_test}" = "yes")
-- 
2.49.0.windows.1

[PATCH BlueZ 2/3] Makefile.am: build `bluetoothd` if enabled

[Francesco Giancane]

Keep daemon compilation and installation steps separated.
---
 Makefile.am | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index fa1003a2f..af30cf6ae 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -31,9 +31,11 @@ AM_LDFLAGS = $(MISC_LDFLAGS)
 confdir = $(sysconfdir)/bluetooth
 statedir = $(localstatedir)/lib/bluetooth
 
+if BLUETOOTHD
 bluetoothd-fix-permissions:
 	install -dm755 $(DESTDIR)$(confdir)
 	install -dm700 $(DESTDIR)$(statedir)
+endif
 
 if DATAFILES
 dbusdir = $(DBUS_CONFDIR)/dbus-1/system.d
@@ -301,7 +303,9 @@ builtin_ldadd =
 
 include Makefile.plugins
 
+if BLUETOOTHD
 pkglibexec_PROGRAMS += src/bluetoothd
+endif
 
 src_bluetoothd_SOURCES = $(builtin_sources) \
 			$(attrib_sources) $(btio_sources) \
@@ -441,7 +445,11 @@ include Makefile.mesh
 if SYSTEMD
 install-data-hook: obexd-add-service-symlink
 else
+if BLUETOOTHD
 install-data-hook: bluetoothd-fix-permissions obexd-add-service-symlink
+else
+install-data-hook: obexd-add-service-symlink
+endif
 endif
 
 uninstall-hook: obexd-remove-service-symlink
-- 
2.49.0.windows.1

[PATCH BlueZ 3/3] README: document `--enable-bluetoothd` flag

[Francesco Giancane]

Document how to enable or disable compilation and installation of
the daemon `bluetoothd`.
---
 README | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/README b/README
index c68f12de3..057f60794 100644
--- a/README
+++ b/README
@@ -107,6 +107,20 @@ For a working system, certain configuration options need to be enabled:
 		idea to use a separate bluez-library or libbluetooth
 		package for it.
 
+	--enable-bluetoothd
+
+		Enable installation of `bluetoothd` daemon
+
+		By default the `bluetoothd` daemon is not installed.
+
+		The `bluetoothd` daemon can be excluded from build.
+		This covers cases where standard BlueZ distribution
+		and tools or libraries are to be provided separately.
+
+		When the daemon installation is enabled, it is a good
+		idea to use a separate bluez-bluetoothd or bluetoothd
+		package for it.
+
 	--disable-tools
 
 		Disable support for Bluetooth utilities
-- 
2.49.0.windows.1

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Luiz Augusto von Dentz]

Hi Francesco,

On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
<quic_fgiancan@quicinc.com> wrote:
>
> Hi,
>
> I am posting this patch series to better decouple `bluetoothd` daemon
> and `libbluetooth`, as mentioned in the subject.
>
> I am introducing this change to make new BlueZ more granular.
> This will allow more control on which components are actually selected
> to build.
>
> Major use case for this change is fixing circular dependencies when
> bootstrapping new builds where the whole build root is to be recreated
> (e.g. Yocto Project).
> In these scenarios, to have Bluetooth support enabled in Python,
> `libbluetooth` is required at build time to be present but the direct
> chain of dependencies would require a Python installation available,
> thus introducing circular dependency.
> Separating the library and header files from the rest allows build
> systems to break the dependency loop.

In theory what we should do to fix this is to add proper header to the
kernel, since libbluetooth is basically just used for syscalls to the
linux-bluetooth subsystem, btw doing that would also fix the likes of:
https://github.com/bluez/bluez/issues/989

> `--enable-bluetoothd` flag is added to the `configure` script and
> it is keeping the same behavior as other flags.
>
> Francesco Giancane (3):
>   configure.ac: introduce `--enable-bluetoothd` flag
>   Makefile.am: build `bluetoothd` if enabled
>   README: document `--enable-bluetoothd` flag
>
>  Makefile.am  |  8 ++++++++
>  README       | 14 ++++++++++++++
>  configure.ac |  4 ++++
>  3 files changed, 26 insertions(+)
>
> --
> 2.49.0.windows.1
>
>


-- 
Luiz Augusto von Dentz

RE: Keep component `bluetoothd` isolated

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=984366

---Test result---

Test Summary:
CheckPatch                    PENDING   0.33 seconds
GitLint                       PENDING   0.31 seconds
BuildEll                      PASS      20.13 seconds
BluezMake                     PASS      2580.32 seconds
MakeCheck                     PASS      20.57 seconds
MakeDistcheck                 PASS      173.89 seconds
CheckValgrind                 PASS      224.76 seconds
CheckSmatch                   PASS      276.91 seconds
bluezmakeextell               PASS      121.88 seconds
IncrementalBuild              PENDING   0.32 seconds
ScanBuild                     PASS      760.46 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hello Luiz,

Thanks for your feedbacks!

On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
> Hi Francesco,
>
> On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
> <quic_fgiancan@quicinc.com> wrote:
>> Hi,
>>
>> I am posting this patch series to better decouple `bluetoothd` daemon
>> and `libbluetooth`, as mentioned in the subject.
>>
>> I am introducing this change to make new BlueZ more granular.
>> This will allow more control on which components are actually selected
>> to build.
>>
>> Major use case for this change is fixing circular dependencies when
>> bootstrapping new builds where the whole build root is to be recreated
>> (e.g. Yocto Project).
>> In these scenarios, to have Bluetooth support enabled in Python,
>> `libbluetooth` is required at build time to be present but the direct
>> chain of dependencies would require a Python installation available,
>> thus introducing circular dependency.
>> Separating the library and header files from the rest allows build
>> systems to break the dependency loop.
> In theory what we should do to fix this is to add proper header to the
> kernel, since libbluetooth is basically just used for syscalls to the
> linux-bluetooth subsystem, btw doing that would also fix the likes of:
> https://github.com/bluez/bluez/issues/989

I see I see. I read through these issues jumping back and forth Python 
(it is interesting that it's covering the exact same case i'd like to 
fix :)).

So if I understand correctly, your suggestion is to remove *our* 
internal headers and rely solely on kernel ones? Or better, move ours 
straight to the kernel UAPI.

I'd like to help here if you can provide more details I can work on a v2.

Thanks for your time,

>
>> `--enable-bluetoothd` flag is added to the `configure` script and
>> it is keeping the same behavior as other flags.
>>
>> Francesco Giancane (3):
>>    configure.ac: introduce `--enable-bluetoothd` flag
>>    Makefile.am: build `bluetoothd` if enabled
>>    README: document `--enable-bluetoothd` flag
>>
>>   Makefile.am  |  8 ++++++++
>>   README       | 14 ++++++++++++++
>>   configure.ac |  4 ++++
>>   3 files changed, 26 insertions(+)
>>
>> --
>> 2.49.0.windows.1
>>
>>
>

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Luiz Augusto von Dentz]

Hi Francesco,

On Mon, Jul 21, 2025 at 1:05 PM Francesco Giancane
<quic_fgiancan@quicinc.com> wrote:
>
> Hello Luiz,
>
> Thanks for your feedbacks!
>
> On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
> > Hi Francesco,
> >
> > On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
> > <quic_fgiancan@quicinc.com> wrote:
> >> Hi,
> >>
> >> I am posting this patch series to better decouple `bluetoothd` daemon
> >> and `libbluetooth`, as mentioned in the subject.
> >>
> >> I am introducing this change to make new BlueZ more granular.
> >> This will allow more control on which components are actually selected
> >> to build.
> >>
> >> Major use case for this change is fixing circular dependencies when
> >> bootstrapping new builds where the whole build root is to be recreated
> >> (e.g. Yocto Project).
> >> In these scenarios, to have Bluetooth support enabled in Python,
> >> `libbluetooth` is required at build time to be present but the direct
> >> chain of dependencies would require a Python installation available,
> >> thus introducing circular dependency.
> >> Separating the library and header files from the rest allows build
> >> systems to break the dependency loop.
> > In theory what we should do to fix this is to add proper header to the
> > kernel, since libbluetooth is basically just used for syscalls to the
> > linux-bluetooth subsystem, btw doing that would also fix the likes of:
> > https://github.com/bluez/bluez/issues/989
>
> I see I see. I read through these issues jumping back and forth Python
> (it is interesting that it's covering the exact same case i'd like to
> fix :)).
>
> So if I understand correctly, your suggestion is to remove *our*
> internal headers and rely solely on kernel ones? Or better, move ours
> straight to the kernel UAPI.

Yes, moving our headers to UAPI is probably the right thing to do,
that said we will need to figure out if we can do this in one step,
and just start depending on it for the start, or if we gonna need to
ship with a copy as libbluetooth and have a transition step, from the
looks of it we will need to do the second option until distro catch up
and start to ship with Bluetooth UAPI headers, anyway we can probably
start with UAPI headers first along with any kernel changes required.

> I'd like to help here if you can provide more details I can work on a v2.
>
> Thanks for your time,
>
> >
> >> `--enable-bluetoothd` flag is added to the `configure` script and
> >> it is keeping the same behavior as other flags.
> >>
> >> Francesco Giancane (3):
> >>    configure.ac: introduce `--enable-bluetoothd` flag
> >>    Makefile.am: build `bluetoothd` if enabled
> >>    README: document `--enable-bluetoothd` flag
> >>
> >>   Makefile.am  |  8 ++++++++
> >>   README       | 14 ++++++++++++++
> >>   configure.ac |  4 ++++
> >>   3 files changed, 26 insertions(+)
> >>
> >> --
> >> 2.49.0.windows.1
> >>
> >>
> >



-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

On 21/07/2025 19:01, Luiz Augusto von Dentz wrote:
> Hi Francesco,
>
> On Mon, Jul 21, 2025 at 1:05 PM Francesco Giancane
> <quic_fgiancan@quicinc.com> wrote:
>> Hello Luiz,
>>
>> Thanks for your feedbacks!
>>
>> On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
>>> Hi Francesco,
>>>
>>> On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
>>> <quic_fgiancan@quicinc.com> wrote:
>>>> Hi,
>>>>
>>>> I am posting this patch series to better decouple `bluetoothd` daemon
>>>> and `libbluetooth`, as mentioned in the subject.
>>>>
>>>> I am introducing this change to make new BlueZ more granular.
>>>> This will allow more control on which components are actually selected
>>>> to build.
>>>>
>>>> Major use case for this change is fixing circular dependencies when
>>>> bootstrapping new builds where the whole build root is to be recreated
>>>> (e.g. Yocto Project).
>>>> In these scenarios, to have Bluetooth support enabled in Python,
>>>> `libbluetooth` is required at build time to be present but the direct
>>>> chain of dependencies would require a Python installation available,
>>>> thus introducing circular dependency.
>>>> Separating the library and header files from the rest allows build
>>>> systems to break the dependency loop.
>>> In theory what we should do to fix this is to add proper header to the
>>> kernel, since libbluetooth is basically just used for syscalls to the
>>> linux-bluetooth subsystem, btw doing that would also fix the likes of:
>>> https://github.com/bluez/bluez/issues/989
>> I see I see. I read through these issues jumping back and forth Python
>> (it is interesting that it's covering the exact same case i'd like to
>> fix :)).
>>
>> So if I understand correctly, your suggestion is to remove *our*
>> internal headers and rely solely on kernel ones? Or better, move ours
>> straight to the kernel UAPI.
> Yes, moving our headers to UAPI is probably the right thing to do,
> that said we will need to figure out if we can do this in one step,
> and just start depending on it for the start, or if we gonna need to
> ship with a copy as libbluetooth and have a transition step, from the
> looks of it we will need to do the second option until distro catch up
> and start to ship with Bluetooth UAPI headers, anyway we can probably
> start with UAPI headers first along with any kernel changes required.

Assuming that we can create headers in kernel, libbluetooth would be at 
this stage a

legacy wrapper around new APIs (which are possibly the same names and 
symbols).

This would help not breaking any of the existing packages and at some 
point when the

majority has moved to linux UAPI we can just drop these headers from bluez.

As long as these changes do not land into kernel uAPI we cannot change 
anything here.

Question: where would you drop them in kernel? I assume it is 
uapi/bluetooth to keep

same path as libbluetooth includes? (Internal Linux kernel headers sit 
in uapi/net/bluetooth).

>> I'd like to help here if you can provide more details I can work on a v2.
>>
>> Thanks for your time,
>>
>>>> `--enable-bluetoothd` flag is added to the `configure` script and
>>>> it is keeping the same behavior as other flags.
>>>>
>>>> Francesco Giancane (3):
>>>>     configure.ac: introduce `--enable-bluetoothd` flag
>>>>     Makefile.am: build `bluetoothd` if enabled
>>>>     README: document `--enable-bluetoothd` flag
>>>>
>>>>    Makefile.am  |  8 ++++++++
>>>>    README       | 14 ++++++++++++++
>>>>    configure.ac |  4 ++++
>>>>    3 files changed, 26 insertions(+)
>>>>
>>>> --
>>>> 2.49.0.windows.1
>>>>
>>>>
>
>

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Luiz Augusto von Dentz]

Hi Francesco,

On Mon, Jul 21, 2025 at 2:17 PM Francesco Giancane
<quic_fgiancan@quicinc.com> wrote:
>
>
> On 21/07/2025 19:01, Luiz Augusto von Dentz wrote:
> > Hi Francesco,
> >
> > On Mon, Jul 21, 2025 at 1:05 PM Francesco Giancane
> > <quic_fgiancan@quicinc.com> wrote:
> >> Hello Luiz,
> >>
> >> Thanks for your feedbacks!
> >>
> >> On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
> >>> Hi Francesco,
> >>>
> >>> On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
> >>> <quic_fgiancan@quicinc.com> wrote:
> >>>> Hi,
> >>>>
> >>>> I am posting this patch series to better decouple `bluetoothd` daemon
> >>>> and `libbluetooth`, as mentioned in the subject.
> >>>>
> >>>> I am introducing this change to make new BlueZ more granular.
> >>>> This will allow more control on which components are actually selected
> >>>> to build.
> >>>>
> >>>> Major use case for this change is fixing circular dependencies when
> >>>> bootstrapping new builds where the whole build root is to be recreated
> >>>> (e.g. Yocto Project).
> >>>> In these scenarios, to have Bluetooth support enabled in Python,
> >>>> `libbluetooth` is required at build time to be present but the direct
> >>>> chain of dependencies would require a Python installation available,
> >>>> thus introducing circular dependency.
> >>>> Separating the library and header files from the rest allows build
> >>>> systems to break the dependency loop.
> >>> In theory what we should do to fix this is to add proper header to the
> >>> kernel, since libbluetooth is basically just used for syscalls to the
> >>> linux-bluetooth subsystem, btw doing that would also fix the likes of:
> >>> https://github.com/bluez/bluez/issues/989
> >> I see I see. I read through these issues jumping back and forth Python
> >> (it is interesting that it's covering the exact same case i'd like to
> >> fix :)).
> >>
> >> So if I understand correctly, your suggestion is to remove *our*
> >> internal headers and rely solely on kernel ones? Or better, move ours
> >> straight to the kernel UAPI.
> > Yes, moving our headers to UAPI is probably the right thing to do,
> > that said we will need to figure out if we can do this in one step,
> > and just start depending on it for the start, or if we gonna need to
> > ship with a copy as libbluetooth and have a transition step, from the
> > looks of it we will need to do the second option until distro catch up
> > and start to ship with Bluetooth UAPI headers, anyway we can probably
> > start with UAPI headers first along with any kernel changes required.
>
> Assuming that we can create headers in kernel, libbluetooth would be at
> this stage a
>
> legacy wrapper around new APIs (which are possibly the same names and
> symbols).
>
> This would help not breaking any of the existing packages and at some
> point when the
>
> majority has moved to linux UAPI we can just drop these headers from bluez.
>
> As long as these changes do not land into kernel uAPI we cannot change
> anything here.
>
> Question: where would you drop them in kernel? I assume it is
> uapi/bluetooth to keep

I guess that would need to be moved into
include/uapi/linux/bluetooth/, I took a brief look and there is also
the likes of sdp.h, sdp_lib.h, hci.h and hci_lib.h, these header are
either exclusive to libbluetooth (SDP) or partially exclusive like HCI
helpers, anyway it should be easy to identify what symbols comes from
the kernel and exclude them from libbluetooth.

> same path as libbluetooth includes? (Internal Linux kernel headers sit
> in uapi/net/bluetooth).

Usually the uapi start with linux/, for example to include uhid we do
#include <linux/uhid.h>, perhaps we can do <linux/bluetooth.h> and
then for each socket family <linux/bluetooth/l2cap.h>, etc.

>
> >> I'd like to help here if you can provide more details I can work on a v2.
> >>
> >> Thanks for your time,
> >>
> >>>> `--enable-bluetoothd` flag is added to the `configure` script and
> >>>> it is keeping the same behavior as other flags.
> >>>>
> >>>> Francesco Giancane (3):
> >>>>     configure.ac: introduce `--enable-bluetoothd` flag
> >>>>     Makefile.am: build `bluetoothd` if enabled
> >>>>     README: document `--enable-bluetoothd` flag
> >>>>
> >>>>    Makefile.am  |  8 ++++++++
> >>>>    README       | 14 ++++++++++++++
> >>>>    configure.ac |  4 ++++
> >>>>    3 files changed, 26 insertions(+)
> >>>>
> >>>> --
> >>>> 2.49.0.windows.1
> >>>>
> >>>>
> >
> >



-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hi Luiz,

Thansk again for your valuable feedback. Dropped some comments inline below.

As a final note: do you think there is value for the time being in 
merging my changes now,

and then eventually removing/simplifying them after moving these .h 
files in UAPI?

On 21/07/2025 21:22, Luiz Augusto von Dentz wrote:
> Hi Francesco,
>
> On Mon, Jul 21, 2025 at 2:17 PM Francesco Giancane
> <quic_fgiancan@quicinc.com> wrote:
>>
>> On 21/07/2025 19:01, Luiz Augusto von Dentz wrote:
>>> Hi Francesco,
>>>
>>> On Mon, Jul 21, 2025 at 1:05 PM Francesco Giancane
>>> <quic_fgiancan@quicinc.com> wrote:
>>>> Hello Luiz,
>>>>
>>>> Thanks for your feedbacks!
>>>>
>>>> On 21/07/2025 17:20, Luiz Augusto von Dentz wrote:
>>>>> Hi Francesco,
>>>>>
>>>>> On Mon, Jul 21, 2025 at 11:24 AM Francesco Giancane
>>>>> <quic_fgiancan@quicinc.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am posting this patch series to better decouple `bluetoothd` daemon
>>>>>> and `libbluetooth`, as mentioned in the subject.
>>>>>>
>>>>>> I am introducing this change to make new BlueZ more granular.
>>>>>> This will allow more control on which components are actually selected
>>>>>> to build.
>>>>>>
>>>>>> Major use case for this change is fixing circular dependencies when
>>>>>> bootstrapping new builds where the whole build root is to be recreated
>>>>>> (e.g. Yocto Project).
>>>>>> In these scenarios, to have Bluetooth support enabled in Python,
>>>>>> `libbluetooth` is required at build time to be present but the direct
>>>>>> chain of dependencies would require a Python installation available,
>>>>>> thus introducing circular dependency.
>>>>>> Separating the library and header files from the rest allows build
>>>>>> systems to break the dependency loop.
>>>>> In theory what we should do to fix this is to add proper header to the
>>>>> kernel, since libbluetooth is basically just used for syscalls to the
>>>>> linux-bluetooth subsystem, btw doing that would also fix the likes of:
>>>>> https://github.com/bluez/bluez/issues/989
>>>> I see I see. I read through these issues jumping back and forth Python
>>>> (it is interesting that it's covering the exact same case i'd like to
>>>> fix :)).
>>>>
>>>> So if I understand correctly, your suggestion is to remove *our*
>>>> internal headers and rely solely on kernel ones? Or better, move ours
>>>> straight to the kernel UAPI.
>>> Yes, moving our headers to UAPI is probably the right thing to do,
>>> that said we will need to figure out if we can do this in one step,
>>> and just start depending on it for the start, or if we gonna need to
>>> ship with a copy as libbluetooth and have a transition step, from the
>>> looks of it we will need to do the second option until distro catch up
>>> and start to ship with Bluetooth UAPI headers, anyway we can probably
>>> start with UAPI headers first along with any kernel changes required.
>> Assuming that we can create headers in kernel, libbluetooth would be at
>> this stage a
>>
>> legacy wrapper around new APIs (which are possibly the same names and
>> symbols).
>>
>> This would help not breaking any of the existing packages and at some
>> point when the
>>
>> majority has moved to linux UAPI we can just drop these headers from bluez.
>>
>> As long as these changes do not land into kernel uAPI we cannot change
>> anything here.
>>
>> Question: where would you drop them in kernel? I assume it is
>> uapi/bluetooth to keep
> I guess that would need to be moved into
> include/uapi/linux/bluetooth/, I took a brief look and there is also
> the likes of sdp.h, sdp_lib.h, hci.h and hci_lib.h, these header are
> either exclusive to libbluetooth (SDP) or partially exclusive like HCI
> helpers, anyway it should be easy to identify what symbols comes from
> the kernel and exclude them from libbluetooth.

Do we need to start a discussion with Linux Kernel RFCing this proposal 
and asking for

more guidance? As you said, posting 10+ patches just dumping whole 
headers would be

probably NAKed.

>
>> same path as libbluetooth includes? (Internal Linux kernel headers sit
>> in uapi/net/bluetooth).
> Usually the uapi start with linux/, for example to include uhid we do
> #include <linux/uhid.h>, perhaps we can do <linux/bluetooth.h> and
> then for each socket family <linux/bluetooth/l2cap.h>, etc.

Ok, I can proceed with this approach and rework UAPI headers to include 
kernel/user

headers. Guess we can keep "private" headers from libbluetooth there.

>
>>>> I'd like to help here if you can provide more details I can work on a v2.
>>>>
>>>> Thanks for your time,
>>>>
>>>>>> `--enable-bluetoothd` flag is added to the `configure` script and
>>>>>> it is keeping the same behavior as other flags.
>>>>>>
>>>>>> Francesco Giancane (3):
>>>>>>      configure.ac: introduce `--enable-bluetoothd` flag
>>>>>>      Makefile.am: build `bluetoothd` if enabled
>>>>>>      README: document `--enable-bluetoothd` flag
>>>>>>
>>>>>>     Makefile.am  |  8 ++++++++
>>>>>>     README       | 14 ++++++++++++++
>>>>>>     configure.ac |  4 ++++
>>>>>>     3 files changed, 26 insertions(+)
>>>>>>
>>>>>> --
>>>>>> 2.49.0.windows.1
>>>>>>
>>>>>>
>>>
>
>

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Bastien Nocera]

On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
> Hi,
> 
> I am posting this patch series to better decouple `bluetoothd` daemon
> and `libbluetooth`, as mentioned in the subject.
> 
> I am introducing this change to make new BlueZ more granular.
> This will allow more control on which components are actually
> selected
> to build.
> 
> Major use case for this change is fixing circular dependencies when
> bootstrapping new builds where the whole build root is to be
> recreated
> (e.g. Yocto Project).
> In these scenarios, to have Bluetooth support enabled in Python,
> `libbluetooth` is required at build time to be present but the direct
> chain of dependencies would require a Python installation available,
> thus introducing circular dependency.
> Separating the library and header files from the rest allows build
> systems to break the dependency loop.

FWIW, I'm currently porting bluez to meson (currently stuck on porting
ell with its gazillion of SSL certificate tests), which would make
python a pre-requirement for bluez (if meson ended up being the only
build system).

What part of Python itself has Bluetooth support? Wouldn't it also be
possible to make that part of Python separate so it can be built after
bluez?

> 
> `--enable-bluetoothd` flag is added to the `configure` script and
> it is keeping the same behavior as other flags.
> 
> Francesco Giancane (3):
>   configure.ac: introduce `--enable-bluetoothd` flag
>   Makefile.am: build `bluetoothd` if enabled
>   README: document `--enable-bluetoothd` flag
> 
>  Makefile.am  |  8 ++++++++
>  README       | 14 ++++++++++++++
>  configure.ac |  4 ++++
>  3 files changed, 26 insertions(+)

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hello!

On 22/07/2025 13:54, Bastien Nocera wrote:
> On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
>> Hi,
>>
>> I am posting this patch series to better decouple `bluetoothd` daemon
>> and `libbluetooth`, as mentioned in the subject.
>>
>> I am introducing this change to make new BlueZ more granular.
>> This will allow more control on which components are actually
>> selected
>> to build.
>>
>> Major use case for this change is fixing circular dependencies when
>> bootstrapping new builds where the whole build root is to be
>> recreated
>> (e.g. Yocto Project).
>> In these scenarios, to have Bluetooth support enabled in Python,
>> `libbluetooth` is required at build time to be present but the direct
>> chain of dependencies would require a Python installation available,
>> thus introducing circular dependency.
>> Separating the library and header files from the rest allows build
>> systems to break the dependency loop.
> FWIW, I'm currently porting bluez to meson (currently stuck on porting
> ell with its gazillion of SSL certificate tests), which would make
> python a pre-requirement for bluez (if meson ended up being the only
> build system).
>
> What part of Python itself has Bluetooth support? Wouldn't it also be
> possible to make that part of Python separate so it can be built after
> bluez?

Python uses autoconf to detect compile-time dependencies.

They implemented Bluetooth network management with standard socket() calls.

This code path is enabled at compile time only if it detects bluetooth.h 
header.

So for python to support Bluetooth in std library, libbluetooth should 
be already deployed.

With this current patch series I posted, you can build a "lite" version 
of bluez to ship just enough

the library and the headers so that python can have bluetooth support 
(building a full BlueZ package requires

python too... hence the circular dependency).

Francesco

>
>> `--enable-bluetoothd` flag is added to the `configure` script and
>> it is keeping the same behavior as other flags.
>>
>> Francesco Giancane (3):
>>    configure.ac: introduce `--enable-bluetoothd` flag
>>    Makefile.am: build `bluetoothd` if enabled
>>    README: document `--enable-bluetoothd` flag
>>
>>   Makefile.am  |  8 ++++++++
>>   README       | 14 ++++++++++++++
>>   configure.ac |  4 ++++
>>   3 files changed, 26 insertions(+)

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Bastien Nocera]

On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
> Hello!
> 
> On 22/07/2025 13:54, Bastien Nocera wrote:
> > On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
> > > Hi,
> > > 
> > > I am posting this patch series to better decouple `bluetoothd`
> > > daemon
> > > and `libbluetooth`, as mentioned in the subject.
> > > 
> > > I am introducing this change to make new BlueZ more granular.
> > > This will allow more control on which components are actually
> > > selected
> > > to build.
> > > 
> > > Major use case for this change is fixing circular dependencies
> > > when
> > > bootstrapping new builds where the whole build root is to be
> > > recreated
> > > (e.g. Yocto Project).
> > > In these scenarios, to have Bluetooth support enabled in Python,
> > > `libbluetooth` is required at build time to be present but the
> > > direct
> > > chain of dependencies would require a Python installation
> > > available,
> > > thus introducing circular dependency.
> > > Separating the library and header files from the rest allows
> > > build
> > > systems to break the dependency loop.
> > FWIW, I'm currently porting bluez to meson (currently stuck on
> > porting
> > ell with its gazillion of SSL certificate tests), which would make
> > python a pre-requirement for bluez (if meson ended up being the
> > only
> > build system).
> > 
> > What part of Python itself has Bluetooth support? Wouldn't it also
> > be
> > possible to make that part of Python separate so it can be built
> > after
> > bluez?
> 
> Python uses autoconf to detect compile-time dependencies.
> 
> They implemented Bluetooth network management with standard socket()
> calls.
> 
> This code path is enabled at compile time only if it detects
> bluetooth.h 
> header.
> 
> So for python to support Bluetooth in std library, libbluetooth
> should 
> be already deployed.
> 
> With this current patch series I posted, you can build a "lite"
> version 
> of bluez to ship just enough
> 
> the library and the headers so that python can have bluetooth support
> (building a full BlueZ package requires
> 
> python too... hence the circular dependency).

Right, so you're trying to do:
- bluez (lib and headers only)
- python (with Bluetooth support)
- bluez (full)

And if meson were the only build system, you'd need to do:
- python (without Bluetooth support)
- bluez (full)
- python (with Bluetooth support)

I guess having a minimal uapi header upstream would allow to do:
- python (with Bluetooth support)
- bluez (full)

Definitely the best option.

I think it might be best to only migrate to the upstream kernel uapi
the minimum needed to build Python with Bluetooth support, and extend
it as needed afterwards.

In the short-term, why not apply your bluez patches to your bluetoothd
recipe rather than upstream? That should also motivate developers to
land the "correct" fix upstream ;)

Cheers

> 
> Francesco
> 
> > 
> > > `--enable-bluetoothd` flag is added to the `configure` script and
> > > it is keeping the same behavior as other flags.
> > > 
> > > Francesco Giancane (3):
> > >    configure.ac: introduce `--enable-bluetoothd` flag
> > >    Makefile.am: build `bluetoothd` if enabled
> > >    README: document `--enable-bluetoothd` flag
> > > 
> > >   Makefile.am  |  8 ++++++++
> > >   README       | 14 ++++++++++++++
> > >   configure.ac |  4 ++++
> > >   3 files changed, 26 insertions(+)

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Luiz Augusto von Dentz]

Hi Bastien,

On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
> > Hello!
> >
> > On 22/07/2025 13:54, Bastien Nocera wrote:
> > > On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
> > > > Hi,
> > > >
> > > > I am posting this patch series to better decouple `bluetoothd`
> > > > daemon
> > > > and `libbluetooth`, as mentioned in the subject.
> > > >
> > > > I am introducing this change to make new BlueZ more granular.
> > > > This will allow more control on which components are actually
> > > > selected
> > > > to build.
> > > >
> > > > Major use case for this change is fixing circular dependencies
> > > > when
> > > > bootstrapping new builds where the whole build root is to be
> > > > recreated
> > > > (e.g. Yocto Project).
> > > > In these scenarios, to have Bluetooth support enabled in Python,
> > > > `libbluetooth` is required at build time to be present but the
> > > > direct
> > > > chain of dependencies would require a Python installation
> > > > available,
> > > > thus introducing circular dependency.
> > > > Separating the library and header files from the rest allows
> > > > build
> > > > systems to break the dependency loop.
> > > FWIW, I'm currently porting bluez to meson (currently stuck on
> > > porting
> > > ell with its gazillion of SSL certificate tests), which would make
> > > python a pre-requirement for bluez (if meson ended up being the
> > > only
> > > build system).
> > >
> > > What part of Python itself has Bluetooth support? Wouldn't it also
> > > be
> > > possible to make that part of Python separate so it can be built
> > > after
> > > bluez?
> >
> > Python uses autoconf to detect compile-time dependencies.
> >
> > They implemented Bluetooth network management with standard socket()
> > calls.
> >
> > This code path is enabled at compile time only if it detects
> > bluetooth.h
> > header.
> >
> > So for python to support Bluetooth in std library, libbluetooth
> > should
> > be already deployed.
> >
> > With this current patch series I posted, you can build a "lite"
> > version
> > of bluez to ship just enough
> >
> > the library and the headers so that python can have bluetooth support
> > (building a full BlueZ package requires
> >
> > python too... hence the circular dependency).
>
> Right, so you're trying to do:
> - bluez (lib and headers only)
> - python (with Bluetooth support)
> - bluez (full)
>
> And if meson were the only build system, you'd need to do:
> - python (without Bluetooth support)
> - bluez (full)
> - python (with Bluetooth support)
>
> I guess having a minimal uapi header upstream would allow to do:
> - python (with Bluetooth support)
> - bluez (full)

+1

> Definitely the best option.
>
> I think it might be best to only migrate to the upstream kernel uapi
> the minimum needed to build Python with Bluetooth support, and extend
> it as needed afterwards.

What sort of Bluetooth support does Python have built-in? I thought
that would use D-Bus like pybluez, etc, but perhaps it has some HCI
and SDP functionality that came built-in with libbluetooth, but its
usability is very limited without the daemon, in fact it probably not
really recommended to do HCI or SDP on the application side nowadays
since we now have management interface that abstract HCI and SDP is
sort of legacy with LE Audio catching up with BR/EDR that will
probably be deprecated at some point, so perhaps we shall work with
Python folks to drop the usage of libbluetooth completely once we have
the UAPI headers.

> In the short-term, why not apply your bluez patches to your bluetoothd
> recipe rather than upstream? That should also motivate developers to
> land the "correct" fix upstream ;)

Yeah, going with intermediate solution will sort of introduce a new
dependency in the form of lib only support which will serve as excuse
not to adopt UAPI as soon as they are available.

> Cheers
>
> >
> > Francesco
> >
> > >
> > > > `--enable-bluetoothd` flag is added to the `configure` script and
> > > > it is keeping the same behavior as other flags.
> > > >
> > > > Francesco Giancane (3):
> > > >    configure.ac: introduce `--enable-bluetoothd` flag
> > > >    Makefile.am: build `bluetoothd` if enabled
> > > >    README: document `--enable-bluetoothd` flag
> > > >
> > > >   Makefile.am  |  8 ++++++++
> > > >   README       | 14 ++++++++++++++
> > > >   configure.ac |  4 ++++
> > > >   3 files changed, 26 insertions(+)
>


-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hello Bastien,

On 22/07/2025 15:03, Bastien Nocera wrote:
> On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
>> Hello!
>>
>> On 22/07/2025 13:54, Bastien Nocera wrote:
>>> On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
>>>> Hi,
>>>>
>>>> I am posting this patch series to better decouple `bluetoothd`
>>>> daemon
>>>> and `libbluetooth`, as mentioned in the subject.
>>>>
>>>> I am introducing this change to make new BlueZ more granular.
>>>> This will allow more control on which components are actually
>>>> selected
>>>> to build.
>>>>
>>>> Major use case for this change is fixing circular dependencies
>>>> when
>>>> bootstrapping new builds where the whole build root is to be
>>>> recreated
>>>> (e.g. Yocto Project).
>>>> In these scenarios, to have Bluetooth support enabled in Python,
>>>> `libbluetooth` is required at build time to be present but the
>>>> direct
>>>> chain of dependencies would require a Python installation
>>>> available,
>>>> thus introducing circular dependency.
>>>> Separating the library and header files from the rest allows
>>>> build
>>>> systems to break the dependency loop.
>>> FWIW, I'm currently porting bluez to meson (currently stuck on
>>> porting
>>> ell with its gazillion of SSL certificate tests), which would make
>>> python a pre-requirement for bluez (if meson ended up being the
>>> only
>>> build system).
>>>
>>> What part of Python itself has Bluetooth support? Wouldn't it also
>>> be
>>> possible to make that part of Python separate so it can be built
>>> after
>>> bluez?
>> Python uses autoconf to detect compile-time dependencies.
>>
>> They implemented Bluetooth network management with standard socket()
>> calls.
>>
>> This code path is enabled at compile time only if it detects
>> bluetooth.h
>> header.
>>
>> So for python to support Bluetooth in std library, libbluetooth
>> should
>> be already deployed.
>>
>> With this current patch series I posted, you can build a "lite"
>> version
>> of bluez to ship just enough
>>
>> the library and the headers so that python can have bluetooth support
>> (building a full BlueZ package requires
>>
>> python too... hence the circular dependency).
> Right, so you're trying to do:
> - bluez (lib and headers only)
> - python (with Bluetooth support)
> - bluez (full)
>
> And if meson were the only build system, you'd need to do:
> - python (without Bluetooth support)
> - bluez (full)
> - python (with Bluetooth support)
>
> I guess having a minimal uapi header upstream would allow to do:
> - python (with Bluetooth support)
> - bluez (full)
>
> Definitely the best option.
>
> I think it might be best to only migrate to the upstream kernel uapi
> the minimum needed to build Python with Bluetooth support, and extend
> it as needed afterwards.
>
> In the short-term, why not apply your bluez patches to your bluetoothd
> recipe rather than upstream? That should also motivate developers to
> land the "correct" fix upstream ;)
>
> Cheers

Thanks for these inputs. I agree that long term extending uapi is the 
best option,

given this scenario.

I was not so much convinced of keeping the downstream patch into Yocto 
recipe as it is extra

maintenance but I see your point. Showing there is already a workaround 
in place can be further

motivation to approve the upstream.

>
>> Francesco
>>
>>>> `--enable-bluetoothd` flag is added to the `configure` script and
>>>> it is keeping the same behavior as other flags.
>>>>
>>>> Francesco Giancane (3):
>>>>     configure.ac: introduce `--enable-bluetoothd` flag
>>>>     Makefile.am: build `bluetoothd` if enabled
>>>>     README: document `--enable-bluetoothd` flag
>>>>
>>>>    Makefile.am  |  8 ++++++++
>>>>    README       | 14 ++++++++++++++
>>>>    configure.ac |  4 ++++
>>>>    3 files changed, 26 insertions(+)

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hello,

On 22/07/2025 15:21, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@hadess.net> wrote:
>> On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
>>> Hello!
>>>
>>> On 22/07/2025 13:54, Bastien Nocera wrote:
>>>> On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
>>>>> Hi,
>>>>>
>>>>> I am posting this patch series to better decouple `bluetoothd`
>>>>> daemon
>>>>> and `libbluetooth`, as mentioned in the subject.
>>>>>
>>>>> I am introducing this change to make new BlueZ more granular.
>>>>> This will allow more control on which components are actually
>>>>> selected
>>>>> to build.
>>>>>
>>>>> Major use case for this change is fixing circular dependencies
>>>>> when
>>>>> bootstrapping new builds where the whole build root is to be
>>>>> recreated
>>>>> (e.g. Yocto Project).
>>>>> In these scenarios, to have Bluetooth support enabled in Python,
>>>>> `libbluetooth` is required at build time to be present but the
>>>>> direct
>>>>> chain of dependencies would require a Python installation
>>>>> available,
>>>>> thus introducing circular dependency.
>>>>> Separating the library and header files from the rest allows
>>>>> build
>>>>> systems to break the dependency loop.
>>>> FWIW, I'm currently porting bluez to meson (currently stuck on
>>>> porting
>>>> ell with its gazillion of SSL certificate tests), which would make
>>>> python a pre-requirement for bluez (if meson ended up being the
>>>> only
>>>> build system).
>>>>
>>>> What part of Python itself has Bluetooth support? Wouldn't it also
>>>> be
>>>> possible to make that part of Python separate so it can be built
>>>> after
>>>> bluez?
>>> Python uses autoconf to detect compile-time dependencies.
>>>
>>> They implemented Bluetooth network management with standard socket()
>>> calls.
>>>
>>> This code path is enabled at compile time only if it detects
>>> bluetooth.h
>>> header.
>>>
>>> So for python to support Bluetooth in std library, libbluetooth
>>> should
>>> be already deployed.
>>>
>>> With this current patch series I posted, you can build a "lite"
>>> version
>>> of bluez to ship just enough
>>>
>>> the library and the headers so that python can have bluetooth support
>>> (building a full BlueZ package requires
>>>
>>> python too... hence the circular dependency).
>> Right, so you're trying to do:
>> - bluez (lib and headers only)
>> - python (with Bluetooth support)
>> - bluez (full)
>>
>> And if meson were the only build system, you'd need to do:
>> - python (without Bluetooth support)
>> - bluez (full)
>> - python (with Bluetooth support)
>>
>> I guess having a minimal uapi header upstream would allow to do:
>> - python (with Bluetooth support)
>> - bluez (full)
> +1
>
>> Definitely the best option.
>>
>> I think it might be best to only migrate to the upstream kernel uapi
>> the minimum needed to build Python with Bluetooth support, and extend
>> it as needed afterwards.
> What sort of Bluetooth support does Python have built-in? I thought
> that would use D-Bus like pybluez, etc, but perhaps it has some HCI
> and SDP functionality that came built-in with libbluetooth, but its
> usability is very limited without the daemon, in fact it probably not
> really recommended to do HCI or SDP on the application side nowadays
> since we now have management interface that abstract HCI and SDP is
> sort of legacy with LE Audio catching up with BR/EDR that will
> probably be deprecated at some point, so perhaps we shall work with
> Python folks to drop the usage of libbluetooth completely once we have
> the UAPI headers.

So I am no Bluetooth expert (not at this level). I was helping a 
colleague running

some Bluetooth applications on an embedded chip using Python and 
basically all of these

scripts were broken because of missing HAVE_BLUETOOTH_BLUETOOTH_H symbol 
(would be defined

with libbluetooth in place). Some time has passed to if details are 
required it may take some time from

me to recover them, but i can do. I clearly recall we were using 
bluetoothd in tandem with this python package

(which allegedly, required built-in bluetooth support to be enabled).

For reference:

https://github.com/python/cpython/blob/main/Modules/socketmodule.h#L116
https://github.com/python/cpython/blob/main/Modules/socketmodule.h#L282

And perhaps more interestingly:
https://github.com/python/cpython/blob/main/Modules/socketmodule.c

>> In the short-term, why not apply your bluez patches to your bluetoothd
>> recipe rather than upstream? That should also motivate developers to
>> land the "correct" fix upstream ;)
> Yeah, going with intermediate solution will sort of introduce a new
> dependency in the form of lib only support which will serve as excuse
> not to adopt UAPI as soon as they are available.

Got it, let's go with the upstream approach then. I do not see any 
blocker besides kernel

discussions here. I am fine deprecating altogether the libbluetooth 
intermediate effort.

On the other side, since you mentioned, I can check which specific 
python libraries were using

libbluetooth and the above code path, to see if they were using already 
the legacy approach or

if it is however something that must be supported in Python.

Thanks!

>> Cheers
>>
>>> Francesco
>>>
>>>>> `--enable-bluetoothd` flag is added to the `configure` script and
>>>>> it is keeping the same behavior as other flags.
>>>>>
>>>>> Francesco Giancane (3):
>>>>>     configure.ac: introduce `--enable-bluetoothd` flag
>>>>>     Makefile.am: build `bluetoothd` if enabled
>>>>>     README: document `--enable-bluetoothd` flag
>>>>>
>>>>>    Makefile.am  |  8 ++++++++
>>>>>    README       | 14 ++++++++++++++
>>>>>    configure.ac |  4 ++++
>>>>>    3 files changed, 26 insertions(+)
>

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Francesco Giancane]

Hello,

On 22/07/2025 15:21, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@hadess.net> wrote:
>> On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
>>> Hello!
>>>
>>> On 22/07/2025 13:54, Bastien Nocera wrote:
>>>> On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
>>>>> Hi,
>>>>>
>>>>> I am posting this patch series to better decouple `bluetoothd`
>>>>> daemon
>>>>> and `libbluetooth`, as mentioned in the subject.
>>>>>
>>>>> I am introducing this change to make new BlueZ more granular.
>>>>> This will allow more control on which components are actually
>>>>> selected
>>>>> to build.
>>>>>
>>>>> Major use case for this change is fixing circular dependencies
>>>>> when
>>>>> bootstrapping new builds where the whole build root is to be
>>>>> recreated
>>>>> (e.g. Yocto Project).
>>>>> In these scenarios, to have Bluetooth support enabled in Python,
>>>>> `libbluetooth` is required at build time to be present but the
>>>>> direct
>>>>> chain of dependencies would require a Python installation
>>>>> available,
>>>>> thus introducing circular dependency.
>>>>> Separating the library and header files from the rest allows
>>>>> build
>>>>> systems to break the dependency loop.
>>>> FWIW, I'm currently porting bluez to meson (currently stuck on
>>>> porting
>>>> ell with its gazillion of SSL certificate tests), which would make
>>>> python a pre-requirement for bluez (if meson ended up being the
>>>> only
>>>> build system).
>>>>
>>>> What part of Python itself has Bluetooth support? Wouldn't it also
>>>> be
>>>> possible to make that part of Python separate so it can be built
>>>> after
>>>> bluez?
>>> Python uses autoconf to detect compile-time dependencies.
>>>
>>> They implemented Bluetooth network management with standard socket()
>>> calls.
>>>
>>> This code path is enabled at compile time only if it detects
>>> bluetooth.h
>>> header.
>>>
>>> So for python to support Bluetooth in std library, libbluetooth
>>> should
>>> be already deployed.
>>>
>>> With this current patch series I posted, you can build a "lite"
>>> version
>>> of bluez to ship just enough
>>>
>>> the library and the headers so that python can have bluetooth support
>>> (building a full BlueZ package requires
>>>
>>> python too... hence the circular dependency).
>> Right, so you're trying to do:
>> - bluez (lib and headers only)
>> - python (with Bluetooth support)
>> - bluez (full)
>>
>> And if meson were the only build system, you'd need to do:
>> - python (without Bluetooth support)
>> - bluez (full)
>> - python (with Bluetooth support)
>>
>> I guess having a minimal uapi header upstream would allow to do:
>> - python (with Bluetooth support)
>> - bluez (full)
> +1
>
>> Definitely the best option.
>>
>> I think it might be best to only migrate to the upstream kernel uapi
>> the minimum needed to build Python with Bluetooth support, and extend
>> it as needed afterwards.
> What sort of Bluetooth support does Python have built-in? I thought
> that would use D-Bus like pybluez, etc, but perhaps it has some HCI
> and SDP functionality that came built-in with libbluetooth, but its
> usability is very limited without the daemon, in fact it probably not
> really recommended to do HCI or SDP on the application side nowadays
> since we now have management interface that abstract HCI and SDP is
> sort of legacy with LE Audio catching up with BR/EDR that will
> probably be deprecated at some point, so perhaps we shall work with
> Python folks to drop the usage of libbluetooth completely once we have
> the UAPI headers.

The library requiring bluetooth headers to be available for Python (and 
thus enabling

bluetooth support in python) is:

https://pypi.org/project/bleak/

>> In the short-term, why not apply your bluez patches to your bluetoothd
>> recipe rather than upstream? That should also motivate developers to
>> land the "correct" fix upstream ;)
> Yeah, going with intermediate solution will sort of introduce a new
> dependency in the form of lib only support which will serve as excuse
> not to adopt UAPI as soon as they are available.
>
>> Cheers
>>
>>> Francesco
>>>
>>>>> `--enable-bluetoothd` flag is added to the `configure` script and
>>>>> it is keeping the same behavior as other flags.
>>>>>
>>>>> Francesco Giancane (3):
>>>>>     configure.ac: introduce `--enable-bluetoothd` flag
>>>>>     Makefile.am: build `bluetoothd` if enabled
>>>>>     README: document `--enable-bluetoothd` flag
>>>>>
>>>>>    Makefile.am  |  8 ++++++++
>>>>>    README       | 14 ++++++++++++++
>>>>>    configure.ac |  4 ++++
>>>>>    3 files changed, 26 insertions(+)
>

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Luiz Augusto von Dentz]

Hi Francesco,

On Tue, Jul 22, 2025 at 12:27 PM Francesco Giancane
<quic_fgiancan@quicinc.com> wrote:
>
> Hello,
>
> On 22/07/2025 15:21, Luiz Augusto von Dentz wrote:
> > Hi Bastien,
> >
> > On Tue, Jul 22, 2025 at 10:10 AM Bastien Nocera <hadess@hadess.net> wrote:
> >> On Tue, 2025-07-22 at 14:26 +0100, Francesco Giancane wrote:
> >>> Hello!
> >>>
> >>> On 22/07/2025 13:54, Bastien Nocera wrote:
> >>>> On Mon, 2025-07-21 at 16:22 +0100, Francesco Giancane wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am posting this patch series to better decouple `bluetoothd`
> >>>>> daemon
> >>>>> and `libbluetooth`, as mentioned in the subject.
> >>>>>
> >>>>> I am introducing this change to make new BlueZ more granular.
> >>>>> This will allow more control on which components are actually
> >>>>> selected
> >>>>> to build.
> >>>>>
> >>>>> Major use case for this change is fixing circular dependencies
> >>>>> when
> >>>>> bootstrapping new builds where the whole build root is to be
> >>>>> recreated
> >>>>> (e.g. Yocto Project).
> >>>>> In these scenarios, to have Bluetooth support enabled in Python,
> >>>>> `libbluetooth` is required at build time to be present but the
> >>>>> direct
> >>>>> chain of dependencies would require a Python installation
> >>>>> available,
> >>>>> thus introducing circular dependency.
> >>>>> Separating the library and header files from the rest allows
> >>>>> build
> >>>>> systems to break the dependency loop.
> >>>> FWIW, I'm currently porting bluez to meson (currently stuck on
> >>>> porting
> >>>> ell with its gazillion of SSL certificate tests), which would make
> >>>> python a pre-requirement for bluez (if meson ended up being the
> >>>> only
> >>>> build system).
> >>>>
> >>>> What part of Python itself has Bluetooth support? Wouldn't it also
> >>>> be
> >>>> possible to make that part of Python separate so it can be built
> >>>> after
> >>>> bluez?
> >>> Python uses autoconf to detect compile-time dependencies.
> >>>
> >>> They implemented Bluetooth network management with standard socket()
> >>> calls.
> >>>
> >>> This code path is enabled at compile time only if it detects
> >>> bluetooth.h
> >>> header.
> >>>
> >>> So for python to support Bluetooth in std library, libbluetooth
> >>> should
> >>> be already deployed.
> >>>
> >>> With this current patch series I posted, you can build a "lite"
> >>> version
> >>> of bluez to ship just enough
> >>>
> >>> the library and the headers so that python can have bluetooth support
> >>> (building a full BlueZ package requires
> >>>
> >>> python too... hence the circular dependency).
> >> Right, so you're trying to do:
> >> - bluez (lib and headers only)
> >> - python (with Bluetooth support)
> >> - bluez (full)
> >>
> >> And if meson were the only build system, you'd need to do:
> >> - python (without Bluetooth support)
> >> - bluez (full)
> >> - python (with Bluetooth support)
> >>
> >> I guess having a minimal uapi header upstream would allow to do:
> >> - python (with Bluetooth support)
> >> - bluez (full)
> > +1
> >
> >> Definitely the best option.
> >>
> >> I think it might be best to only migrate to the upstream kernel uapi
> >> the minimum needed to build Python with Bluetooth support, and extend
> >> it as needed afterwards.
> > What sort of Bluetooth support does Python have built-in? I thought
> > that would use D-Bus like pybluez, etc, but perhaps it has some HCI
> > and SDP functionality that came built-in with libbluetooth, but its
> > usability is very limited without the daemon, in fact it probably not
> > really recommended to do HCI or SDP on the application side nowadays
> > since we now have management interface that abstract HCI and SDP is
> > sort of legacy with LE Audio catching up with BR/EDR that will
> > probably be deprecated at some point, so perhaps we shall work with
> > Python folks to drop the usage of libbluetooth completely once we have
> > the UAPI headers.
>
> The library requiring bluetooth headers to be available for Python (and
> thus enabling
>
> bluetooth support in python) is:
>
> https://pypi.org/project/bleak/
>
> >> In the short-term, why not apply your bluez patches to your bluetoothd
> >> recipe rather than upstream? That should also motivate developers to
> >> land the "correct" fix upstream ;)
> > Yeah, going with intermediate solution will sort of introduce a new
> > dependency in the form of lib only support which will serve as excuse
> > not to adopt UAPI as soon as they are available.

I guess we should probably create a github issue or perhaps update the
issue https://github.com/bluez/bluez/issues/989 to avoid having this
conversation lost in the email threads, also I may take the lead in
doing the uapi conversion if no-one has started doing it already,
since that may prevent people from using the kernel interfaces just
because they cannot use the headers due to improper license.

> >
> >> Cheers
> >>
> >>> Francesco
> >>>
> >>>>> `--enable-bluetoothd` flag is added to the `configure` script and
> >>>>> it is keeping the same behavior as other flags.
> >>>>>
> >>>>> Francesco Giancane (3):
> >>>>>     configure.ac: introduce `--enable-bluetoothd` flag
> >>>>>     Makefile.am: build `bluetoothd` if enabled
> >>>>>     README: document `--enable-bluetoothd` flag
> >>>>>
> >>>>>    Makefile.am  |  8 ++++++++
> >>>>>    README       | 14 ++++++++++++++
> >>>>>    configure.ac |  4 ++++
> >>>>>    3 files changed, 26 insertions(+)
> >



-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ 0/3] Keep component `bluetoothd` isolated

[Bastien Nocera]

On Wed, 2025-10-01 at 15:47 -0400, Luiz Augusto von Dentz wrote:
> Hi Francesco,
> 

> <snip>

> I guess we should probably create a github issue or perhaps update
> the
> issue https://github.com/bluez/bluez/issues/989 to avoid having this
> conversation lost in the email threads, also I may take the lead in
> doing the uapi conversion if no-one has started doing it already,
> since that may prevent people from using the kernel interfaces just
> because they cannot use the headers due to improper license.

For what it's worth, I modified the bluez meson port this evening,
fixed the client being always built (my mistake), and implemented not
building bluetoothd:
https://github.com/hadess/bluez/commit/f0e75d1a07efef82538c1b85d35a76b3a8818a2c

The branch at:
https://github.com/hadess/bluez/tree/wip/hadess/add-meson
can be built with just the library and headers by building with meson
using those options:
-Dauto_features=disabled -Dtools=disabled -Dmonitor=disabled -Dclient=disabled -Ddaemon=disabled -Dsystemd=disabled -Dlogind=disabled -Ddatafiles=disabled -Dlibrary=enabled

Cheers