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. > 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
