Benjamin Tissoires [off-list ref] writes:

On Thu, May 19, 2022 at 10:39 AM Christoph Hellwig [off-list ref] wrote:

quoted

On Thu, May 19, 2022 at 10:20:35AM +0200, Greg KH wrote:

quoted

quoted

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.

quoted

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?)

-Toke