On Thu, May 19, 2022 at 01:10:48AM -0700, Christoph Hellwig wrote:

quoted

The logic is the following (see also the last patch for some more
documentation):
- hid-bpf first preloads a BPF program in the kernel that does a few
  things:
   * find out which attach_btf_id are associated with our trace points
   * adds a bpf_tail_call() BPF program that I can use to "call" any
     other BPF program stored into a jump table
   * monitors the releases of struct bpf_prog, and when there are no
     other users than us, detach the bpf progs from the HID devices
- users then declare their tracepoints and then call
  hid_bpf_attach_prog() in a SEC("syscall") program
- hid-bpf then calls multiple time the bpf_tail_call() program with a
  different index in the jump table whenever there is an event coming
  from a matching HID device

So driver abstractions like UDI are now perfectly fine as long as they
are written using a hip new VM?

Ugh, don't mention UDI, that's a bad flashback...

This whole idea seems like a bad idea, against the Linux spirit and
now actually useful - it is totally trivial to write a new HID
driver alreay, and if it isn't in some cases we need to fix that.

So a big fat NAK to the idea of using eBPF for actual driver logic.

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.

So that would just be exception handling.  I don't think you can write a
real HID driver here at all, but I could be wrong as I have not read the
new patchset (older versions of this series could not do that.)

thanks,

greg k-h