Messages in this thread | | | Date | Mon, 25 Apr 2022 21:03:14 -0700 | From | Alexei Starovoitov <> | Subject | Re: [RFC bpf-next v4 0/7] Introduce eBPF support for HID devices (new attempt) |
| |
On Thu, Apr 21, 2022 at 04:07:33PM +0200, Benjamin Tissoires wrote: > Hi, > > so after the reviews from v3, and some discussion with Alexei, I am > back with a new version of HID-BPF. > > This version is not complete (thus the RFC), but I'd like to share > it now to get initial feedback, in case I am too far from the actual > goal. > > FTR, the goal is to provide some changes in the core verifier/btf so > that we can plug in HID-BPF independently from BPF core. This way we can > extend it without having to care about bpf-next.
Overall looks great. imo much cleaner, simpler and more extensible than the earlier versions. The bpf core extensions are nicely contained and HID side can be worked on in parallel.
> The things I am not entirely sure are: > - do we need only fentry/fexit/fmod_ret BPF program types or should > programs that modify the data stream use a different kind?
Probably not. I'll reply in patch 2.
> - patch 3/7 is probably not the correct approach (see comments in the > patch itself) > > We are missing quite a few bits here: > - selftests for patches 1 to 4 > - add the ability to attach a program to a struct device, and run that > program only for that struct device
yes. That is still to be figured out.
> - when running through bpf_prog_test_run_opts, how can we ensure we are > talking to the correct device? (I have a feeling this is linked to the > previous point) > - how can we reconnect the device when a report descriptor fixup BPF > program is loaded (would it make sense to allow some notifications on > when a BPF program is attached/detached to a device, and which > function have been traced?)
Not sure I follow. What kind of notification do you have in mind? To user space?
| |