On Thu, Feb 24, 2022 at 06:41:18PM +0100, Bastien Nocera wrote: > On Thu, 2022-02-24 at 12:31 +0100, Greg KH wrote: > > On Thu, Feb 24, 2022 at 12:08:22PM +0100, Benjamin Tissoires wrote: > > > Hi there, > > > > > > This series introduces support of eBPF for HID devices. > > > > > > I have several use cases where eBPF could be interesting for those > > > input devices: > > > > > > - simple fixup of report descriptor: > > > > > > In the HID tree, we have half of the drivers that are "simple" and > > > that just fix one key or one byte in the report descriptor. > > > Currently, for users of such devices, the process of fixing them > > > is long and painful. > > > With eBPF, we could externalize those fixups in one external repo, > > > ship various CoRe bpf programs and have those programs loaded at > > > boot > > > time without having to install a new kernel (and wait 6 months for > > > the > > > fix to land in the distro kernel) > > > > Why would a distro update such an external repo faster than they > > update > > the kernel? Many sane distros update their kernel faster than other > > packages already, how about fixing your distro? :) > > > > I'm all for the idea of using ebpf for HID devices, but now we have > > to > > keep track of multiple packages to be in sync here. Is this making > > things harder overall? > > I don't quite understand how taking eBPF quirks for HID devices out of > the kernel tree is different from taking suspend quirks out of the > kernel tree: > https://www.spinics.net/lists/linux-usb/msg204506.html A list of all devices possible, and the policy decisions to make on those devices, belongs in userspace, not in the kernel. That's what the hwdb contains. Quirks in order to get the device to work properly is not a policy decision, they are needed to get the device to work. If you wish to suspend it or not based on the vendor/product id, in order to possibly save some more battery life on some types of systems, is something that belongs in userspace. If you want to replace the existing HID quirk tables with an ebpf program that ships with the kernel, wonderful, I have no objection to that. If a user is required to download the external quirk table just to get their device to work with the kernel, that's probably something you don't want to do. thanks, greg k-h
