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 01A54C433FE for ; Thu, 19 May 2022 08:11:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235216AbiESILJ (ORCPT ); Thu, 19 May 2022 04:11:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235207AbiESILF (ORCPT ); Thu, 19 May 2022 04:11:05 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F2FA32ED4; Thu, 19 May 2022 01:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=P7hBfgfR5V/lg9pLTdIBC/hWy6eM9dq7h/FVFtkFAq8=; b=rdosXHdo2i8UPLrk/NfgCsQQXa NceHcHgDpc15rlXcvlJlOrvKZ07wttU2W4xYEEJ6/rwixNTeoFQGrtYIfP88p3Ebs08aAqDTCIgNz pLdQx96nbRVquBG/2pxsNXQCMYj08yyvHjs1NkoW9tWhq0aCFNmUPZVm0RT+FxOycqrOLtkimO1gU qVdbj5lP7g6hJLzWrzaga1BFb3fwvsbBm6/6U5xAB3UEw/VdGyTJZ6qYAs7dAErfDL0kHi1ZTR5jm OpDM/iSINt2WRl+K0pmS1DIg6BnDkcGe3O+dUNeHJrXrDUtyifs6d74AsrJbhyhbCDXwNL+hCKQCR CXtb89mQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrbFA-005iMY-O2; Thu, 19 May 2022 08:10:48 +0000 Date: Thu, 19 May 2022 01:10:48 -0700 From: Christoph Hellwig To: Benjamin Tissoires Cc: Greg KH , Jiri Kosina , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , Dave Marchevsky , Joe Stringer , Jonathan Corbet , Tero Kristo , linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices Message-ID: References: <20220518205924.399291-1-benjamin.tissoires@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220518205924.399291-1-benjamin.tissoires@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org > The logic is the following (see also the last patch for some more > documentation): > - hid-bpf first preloads a BPF program in the kernel that does a few > things: > * find out which attach_btf_id are associated with our trace points > * adds a bpf_tail_call() BPF program that I can use to "call" any > other BPF program stored into a jump table > * monitors the releases of struct bpf_prog, and when there are no > other users than us, detach the bpf progs from the HID devices > - users then declare their tracepoints and then call > hid_bpf_attach_prog() in a SEC("syscall") program > - hid-bpf then calls multiple time the bpf_tail_call() program with a > different index in the jump table whenever there is an event coming > from a matching HID device So driver abstractions like UDI are now perfectly fine as long as they are written using a hip new VM? This whole idea seems like a bad idea, against the Linux spirit and now actually useful - it is totally trivial to write a new HID driver alreay, and if it isn't in some cases we need to fix that. So a big fat NAK to the idea of using eBPF for actual driver logic.