lkml.org 
[lkml]   [2022]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices
    From


    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.
    [...]

    \
     
     \ /
      Last update: 2022-02-24 18:21    [W:5.007 / U:0.356 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site