From: Greg KH <gregkh@linuxfoundation.org>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>, Shuah Khan <shuah@kernel.org>,
Dave Marchevsky <davemarchevsky@fb.com>,
Joe Stringer <joe@cilium.io>,
Tero Kristo <tero.kristo@linux.intel.com>,
lkml <linux-kernel@vger.kernel.org>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Peter Hutterer <peter.hutterer@redhat.com>
Subject: Re: [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices
Date: Fri, 25 Feb 2022 17:23:11 +0100 [thread overview]
Message-ID: <YhkCbws+csQyIDKQ@kroah.com> (raw)
In-Reply-To: <CAO-hwJJpJf-GHzU7-9bhMz7OydNPCucTtrm=-GeOf-Ee5-aKrw@mail.gmail.com>
HID selftests question for now:
On Fri, Feb 25, 2022 at 05:00:53PM +0100, Benjamin Tissoires wrote:
> > > 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.
> >
> > Why isn't the hid regression tests in the kernel tree also? That would
> > allow all of the testers out there to test things much easier than
> > having to suck down another test repo (like Linaro and 0-day and
> > kernelci would be forced to do).
>
> 2 years ago I would have argued that the ease of development of
> gitlab.fd.o was more suited to a fast moving project.
>
> Now... The changes in the core part of the code don't change much so
> yes, merging it in the kernel might have a lot of benefits outside of
> what you said. The most immediate one is that I could require fixes to
> be provided with a test, and merge them together, without having to
> hold them until Linus releases a new version.
Yes, having a test be required for a fix is a great idea. Many
subsystems do this already and it helps a lot.
> If nobody complains of having the regression tests in python with
> pytest and some Python 3.6+ features, that is definitely something I
> should look for.
Look at the tools/testing/selftests/ directory today. We already have
python3 tests in there, and as long as you follow the proper TAP output
format, all should be fine. The tc-testing python code in the kernel
trees seems to do that and no one has complained yet :)
thanks,
greg k-h
next prev parent reply other threads:[~2022-02-25 16:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 11:08 [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 1/6] HID: initial BPF implementation Benjamin Tissoires
2022-02-24 11:34 ` Greg KH
2022-02-24 13:52 ` Benjamin Tissoires
2022-02-28 17:30 ` Benjamin Tissoires
2022-02-26 7:19 ` Song Liu
2022-02-28 17:38 ` Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 2/6] HID: bpf: allow to change the report descriptor from an eBPF program Benjamin Tissoires
2022-02-26 7:25 ` Song Liu
2022-02-28 17:41 ` Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 3/6] HID: bpf: add hid_{get|set}_data helpers Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 4/6] HID: bpf: add new BPF type to trigger commands from userspace Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 5/6] HID: bpf: tests: rely on uhid event to know if a test device is ready Benjamin Tissoires
2022-02-24 11:08 ` [PATCH bpf-next v1 6/6] HID: bpf: add bpf_hid_raw_request helper function Benjamin Tissoires
2022-02-24 11:31 ` [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices Greg KH
2022-02-24 13:49 ` Benjamin Tissoires
2022-02-24 17:20 ` Yonghong Song
2022-02-25 16:06 ` Benjamin Tissoires
2022-02-25 16:19 ` Greg KH
2022-02-25 16:30 ` Yonghong Song
2022-02-25 13:38 ` Greg KH
2022-02-25 16:00 ` Benjamin Tissoires
2022-02-25 16:23 ` Greg KH [this message]
2022-02-25 16:32 ` Greg KH
2022-02-26 7:36 ` Song Liu
2022-02-26 9:19 ` Benjamin Tissoires
2022-02-28 16:33 ` Jiri Kosina
2022-02-24 17:41 ` Bastien Nocera
2022-02-24 18:20 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhkCbws+csQyIDKQ@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=benjamin.tissoires@redhat.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davemarchevsky@fb.com \
--cc=jikos@kernel.org \
--cc=joe@cilium.io \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peter.hutterer@redhat.com \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=tero.kristo@linux.intel.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.