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