On 2/25/22 8:06 AM, Benjamin Tissoires wrote:
On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song <yhs@xxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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?
Yes. You can. See the example at kernel/bpf/preload directory.
The example will pin the link (holding a reference to the program)
into bpffs (implemented in kernel/bpf/inode.c).
Later on, in userspace, you can grab a fd from bpffs pinned link and use
BPF_LINK_UPDATE to update the program if you want. This way,
if your driver uses the link to get the program, they will
automatically get the new program in the next run.
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. >
Cheers,
Benjamin
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.
[...]
