From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: Alan Maguire <alan.maguire@oracle.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
Shuah Khan <shuah@kernel.org>
Cc: ebpf@linuxfoundation.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 1/3] selftests/bpf: do not disable /dev/null device access in cgroup dev test
Date: Tue, 30 Jul 2024 10:42:04 +0200 [thread overview]
Message-ID: <df287de3-8b06-42dd-8353-fae5cffae6a2@bootlin.com> (raw)
In-Reply-To: <012176d7-646b-49fe-b139-c8072340ecdb@oracle.com>
On 7/30/24 10:16, Alan Maguire wrote:
> On 29/07/2024 18:30, Alexis Lothoré wrote:
>> Hello Alan,
[...]
>>> Not a big deal, but I found it a bit confusing that this file was
>>> modified then deleted in patch 2. Would it work having patch 1 stop
>>> building the standalone test/remove it and .gitignore entry, patch 2
>>> updating progs/dev_cgroup.c to allow /dev/zero, /dev/urandom access,
>>> patch 3 add cgroup_dev.c test support, and patch 4 add the device type
>>> subtest? Or are there issues with doing things that way? Thanks!
>>
>> I've done this to make sure that at any point in the git history, there is one
>> working test for the targeted feature, either the old or the new one. I've done
>> it this way because the old test also helped me validate the new one while
>> developing it, but also because if at some point there is a (major) issue with
>> the new test, reverting only the relevant commit brings back the old test while
>> disabling the new one.
>>
>> But maybe this concern is not worth the trouble (especially since the old tests
>> are not run automatically) ? If that's indeed the case, I can do it the way you
>> are suggesting :)
>>
>
> If no-one complains, it seems fine to me to stick with the way you've
> constructed the series the next respin. Thanks!
ACK, thanks, I'll keep it that way then.
For the record, I am accumulating a few other converted tests that I will send
soon, and those follow the same logic (keeping one working test at any point of
time, and pushing it to the point where I start by fixing broken tests before
converting those), so if anyone has an opinion in favor of this or rather in
favor of Alan's suggestion, do not hesitate to share it, so I can adjust before
sending.
Thanks,
>
>> Thanks,
>>
>> Alexis
>>
>
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2024-07-30 8:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 8:20 [PATCH bpf-next v2 0/3] selftests/bpf: convert test_dev_cgroup to test_progs Alexis Lothoré (eBPF Foundation)
2024-07-29 8:20 ` [PATCH bpf-next v2 1/3] selftests/bpf: do not disable /dev/null device access in cgroup dev test Alexis Lothoré (eBPF Foundation)
2024-07-29 16:59 ` Alan Maguire
2024-07-29 17:30 ` Alexis Lothoré
2024-07-30 8:16 ` Alan Maguire
2024-07-30 8:42 ` Alexis Lothoré [this message]
2024-07-29 8:20 ` [PATCH bpf-next v2 2/3] selftests/bpf: convert test_dev_cgroup to test_progs Alexis Lothoré (eBPF Foundation)
2024-07-29 17:29 ` Alan Maguire
2024-07-29 17:47 ` Alexis Lothoré
2024-07-29 18:15 ` Alan Maguire
2024-07-29 8:20 ` [PATCH bpf-next v2 3/3] selftests/bpf: add wrong type test to cgroup dev Alexis Lothoré (eBPF Foundation)
2024-07-29 17:40 ` Alan Maguire
2024-07-29 21:54 ` [PATCH bpf-next v2 0/3] selftests/bpf: convert test_dev_cgroup to test_progs Stanislav Fomichev
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=df287de3-8b06-42dd-8353-fae5cffae6a2@bootlin.com \
--to=alexis.lothore@bootlin.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ebpf@linuxfoundation.org \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox