On Mon, 2021-11-22 at 15:46 -0800, Luiz Augusto von Dentz wrote: > 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. Let's say you want to use a KEY_* definition that was recently added to the kernel, what would you do? > > 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. You're talking about the state of things now, I'm talking about the compilation failures once you rely on a slightly newer header that isn't shipped with a distribution. But if you're willing to react to the compilation failure in the future, I can't really stand in your way. It just seems weird to do this now just to undo it the moment you'll need a slightly newer kernel header. Cheers
