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@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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
