From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3427C43219 for ; Fri, 25 Feb 2022 16:06:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242617AbiBYQHW (ORCPT ); Fri, 25 Feb 2022 11:07:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242557AbiBYQHV (ORCPT ); Fri, 25 Feb 2022 11:07:21 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E25E121131A for ; Fri, 25 Feb 2022 08:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645805208; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JtNsOA458FeQEet3eOy2MiWL9UbbHGcWhapQcMGFooY=; b=PweZyL7xPWAEEVoNq86O7Nb9MS2iKy6OrrFHIClV0ROulEoKu9HOmw+GBjeJ7bWyoyPM/G mX7L1GRzkebrpXo6HxEee23Dp5h9l1e3yG0sI2Dz+wK6f59G3MOzGkuRryGZZ5hrWknUTs eq4C9S+kv5ubFuvoLv2eCS9poH6IifY= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-248-4YxDbgHCO5aNt7Uc0FUZOQ-1; Fri, 25 Feb 2022 11:06:44 -0500 X-MC-Unique: 4YxDbgHCO5aNt7Uc0FUZOQ-1 Received: by mail-pj1-f69.google.com with SMTP id y1-20020a17090a644100b001bc901aba0dso2916854pjm.8 for ; Fri, 25 Feb 2022 08:06:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JtNsOA458FeQEet3eOy2MiWL9UbbHGcWhapQcMGFooY=; b=5rTbUSDqbMI83ojz6D6ZM9u1PxkxXeKdA3ZH9VdA2/R7RXyh+y6Ttd5717cq+B2ORv hlp0pDAGCCscmpu7uc9n9zPAne15VgJmgP9N2GppkCni0xHP0T4sSu/I+11Ri6sfx610 XNdvBNwLaTWGnWkxYXqopTOYRH1vAikVBL+SQuW528a0t5YFZFGpKVFDTdiWPDjLoW5P fhlPLK8AEXICg4kN/BI3EfVgbm/aQfHjrG2+FoRd7W1KTELHprQz9l168vtdgLE/TsQC 2xmUUQfNBm1R0PzkkuxCDClSJWI2XIX+Nab/8eDjdZ0Jrfh8HUYbH8LDhoH6zAfUnNEC szMw== X-Gm-Message-State: AOAM531smTvUbAutzeow/cFPzoq+uZaBksPfbup0nFISpbV3MNaJ2IUB OBpsSfzPELySmYShpM0nryRtpSzv0JiyDhcCisjoU7AXKVVoqlKluyY7HUVy/MPwR4WpVrIBGCQ Z2QHssp1Hyil/KFe2ibMwK/KABxzFXEB3sOBeij0= X-Received: by 2002:a17:902:9308:b0:14e:def5:e6b5 with SMTP id bc8-20020a170902930800b0014edef5e6b5mr8295954plb.73.1645805203635; Fri, 25 Feb 2022 08:06:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJwUIpWXteQHikzWnedR/pQmtGNKJt81L52dh8Zvx5yBKuSs0mA4pDWiMKp+ELlQrYIZ5T2VI/o7I3Fd2NGvn7E= X-Received: by 2002:a17:902:9308:b0:14e:def5:e6b5 with SMTP id bc8-20020a170902930800b0014edef5e6b5mr8295906plb.73.1645805203288; Fri, 25 Feb 2022 08:06:43 -0800 (PST) MIME-Version: 1.0 References: <20220224110828.2168231-1-benjamin.tissoires@redhat.com> In-Reply-To: From: Benjamin Tissoires Date: Fri, 25 Feb 2022 17:06:32 +0100 Message-ID: Subject: Re: [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices To: Yonghong Song Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , Tero Kristo , lkml , "open list:HID CORE LAYER" , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, Peter Hutterer Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song 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 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? 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. > [...] >