On Fri, Feb 25, 2022 at 05:06:32PM +0100, Benjamin Tissoires wrote:
On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song yhs@fb.com wrote:
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.
Thanks. This is indeed interesting. I am not sure the exact usage of it though :)
One thing I wonder too while we are on this topic, is it possible to load a bpf program from the kernel directly, in the same way we can request firmwares?
We used to be able to do that, putting bpf programs inside a module. But that might have gotten removed because no one actually used it. I thought it was a nice idea.
Because if we can do that, in my HID use case we could replace simple drivers with bpf programs entirely and reduce the development cycle to a bare minimum.
How would the development cycle change? You could get rid of many in-kernel hid drivers and replace them with bpf code perhaps? Maybe that's a good use case :)
thanks,
greg k-h