Hi Batien, >>>> 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. if I can’t build the tarballs on 5.10.0-7-powerpc, then they don’t get released. Regards Marcel
