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?
