On Thu, May 19, 2022 at 01:10:48AM -0700, Christoph Hellwig wrote:
> > 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
