Hi Bastien, On Mon, Nov 22, 2021 at 3:06 PM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > On Mon, 2021-11-22 at 13:17 -0800, Luiz Augusto von Dentz wrote: > > From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > > > > uhid.h is part of kernel uapi nowadays so it can be included > > directly from linux/uhid.h so this removes the local copy to use it > > instead. > > This will cause the same problems that importing those headers into the > repository was supposed to solve. If you remove those headers, then > older distributions will be stuck on old kernel headers, and bluez > compilations will regularly fail when it uses new structs, struct > members, functions, or constants that are in the upstream uapi headers > but not yet propagated to the user's distribution. I'm not following you on this, the distros don't have uapi headers that match their kernel release? Afaik being a kernel uapi means these APIs are considered stable and I suspect they haven't been changed in a while, you are right that this introduces a kernel dependency if we were to use new members but I still think this is better than having copies that at some point goes out of sync, specially when nothing indicates that things like input_event was not accepted by the kernel. > Strong NAK on this one and the uinput header change too. I didn't introduce the usage of any new symbols, so the only new requirement is that linux/uinput.h and linux/uhid.h headers exist, I could however rollback if we have another way to check if those headers exists use then otherwise we can keep using copies, perhaps move then under linux/ directory, anyway it is not like we don't have kernel dependencies already and we actually have been debating on having the bluetooth socket definitions as part of the uapi instead of libbluetooth, so we will need to sort out how we can update the userspace parts with new kernel interface without breaking the build on systems that don't actually ship with e.g. linux/bluetooth.h. -- Luiz Augusto von Dentz
