On Thu, May 19, 2022 at 12:43 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> writes: > > > On Thu, May 19, 2022 at 10:39 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > >> > >> On Thu, May 19, 2022 at 10:20:35AM +0200, Greg KH wrote: > >> > > are written using a hip new VM? > >> > > >> > Ugh, don't mention UDI, that's a bad flashback... > >> > >> But that is very much what we are doing here. > >> > >> > I thought the goal here was to move a lot of the quirk handling and > >> > "fixup the broken HID decriptors in this device" out of kernel .c code > >> > and into BPF code instead, which this patchset would allow. > > > > Yes, quirks are a big motivation for this work. Right now half of the > > HID drivers are less than 100 lines of code, and are just trivial > > fixes (one byte in the report descriptor, one key mapping, etc...). > > Using eBPF for those would simplify the process from the user point of > > view: you drop a "firmware fix" as an eBPF program in your system and > > you can continue working on your existing kernel. > > How do you envision those BPF programs living, and how would they be > distributed? (In-tree / out of tree?) > As Greg mentioned in his reply, report descriptors fixups don't do much besides changing a memory buffer at probe time. So we can either have udev load the program, pin it and forget about it, or we can also have the kernel do that for us. So I envision the distribution to be hybrid: - for plain fixups where no userspace is required, we should distribute those programs in the kernel itself, in-tree. This series already implements pre-loading of BPF programs for the core part of HID-BPF, but I plan on working on some automation of pre-loading of these programs from the kernel itself when we need to do so. Ideally, the process would be: * user reports a bug * developer produces an eBPF program (and maybe compile it if the user doesn't have LLVM) * user tests/validates the fix without having to recompile anything * developer drops the program in-tree * some automated magic happens (still unclear exactly how to define which HID device needs which eBPF program ATM) * when the kernel sees this exact same device (BUS/VID/PID/INTERFACE) it loads the fixup - the other part of the hybrid solution is for when userspace is heavily involved (because it exports a new dbus interface for that particular feature on this device). We can not really automatically preload the BPF program because we might not have the user in front of it. So in that case, the program would be hosted alongside the application, out-of-the-tree, but given that to be able to call kernel functions you need to be GPL, some public distribution of the sources is required. Cheers, Benjamin
