Messages in this thread | | | Date | Thu, 24 Feb 2022 09:20:39 -0800 | Subject | Re: [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices | From | Yonghong Song <> |
| |
On 2/24/22 5:49 AM, Benjamin Tissoires wrote: > Hi Greg, > > Thanks for the quick answer :) > > On Thu, Feb 24, 2022 at 12:31 PM Greg KH <gregkh@linuxfoundation.org> wrote: >> >> On Thu, Feb 24, 2022 at 12:08:22PM +0100, Benjamin Tissoires wrote: >>> Hi there, >>> >>> This series introduces support of eBPF for HID devices. >>> >>> I have several use cases where eBPF could be interesting for those >>> input devices: >>> >>> - simple fixup of report descriptor: >>> >>> In the HID tree, we have half of the drivers that are "simple" and >>> that just fix one key or one byte in the report descriptor. >>> Currently, for users of such devices, the process of fixing them >>> is long and painful. >>> With eBPF, we could externalize those fixups in one external repo, >>> ship various CoRe bpf programs and have those programs loaded at boot >>> time without having to install a new kernel (and wait 6 months for the >>> fix to land in the distro kernel) >> >> Why would a distro update such an external repo faster than they update >> the kernel? Many sane distros update their kernel faster than other >> packages already, how about fixing your distro? :) > > Heh, I'm going to try to dodge the incoming rhel bullet :) > > It's true that thanks to the work of the stable folks we don't have to > wait 6 months for a fix to come in. However, I think having a single > file to drop in a directory would be easier for development/testing > (and distribution of that file between developers/testers) than > requiring people to recompile their kernel. > > Brain fart: is there any chance we could keep the validated bpf > programs in the kernel tree?
Yes, see kernel/bpf/preload/iterators/iterators.bpf.c.
> >> >> I'm all for the idea of using ebpf for HID devices, but now we have to >> keep track of multiple packages to be in sync here. Is this making >> things harder overall? > > Probably, and this is also maybe opening a can of worms. Vendors will > be able to say "use that bpf program for my HID device because the > firmware is bogus". > > OTOH, as far as I understand, you can not load a BPF program in the > kernel that uses GPL-declared functions if your BPF program is not > GPL. Which means that if firmware vendors want to distribute blobs > through BPF, either it's GPL and they have to provide the sources, or > it's not happening. > > I am not entirely clear on which plan I want to have for userspace. > I'd like to have libinput on board, but right now, Peter's stance is > "not in my garden" (and he has good reasons for it). > So my initial plan is to cook and hold the bpf programs in hid-tools, > which is the repo I am using for the regression tests on HID. > > I plan on building a systemd intrinsic that would detect the HID > VID/PID and then load the various BPF programs associated with the > small fixes. > Note that everything can not be fixed through eBPF, simply because at > boot we don't always have the root partition mounted. [...]
| |