2023-11-21 01:38 UTC+0000 ~ Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx>
> On Thu, Nov 16, 2023 at 11:43 AM Manu Bretelle <chantr4@xxxxxxxxx> wrote:
>>
>> +++ b/tools/testing/selftests/bpf/bpftool_tests/src/bpftool_tests.rs
>> @@ -0,0 +1,20 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>> +use std::process::Command;
>> +
>> +const BPFTOOL_PATH_ENV: &str = "BPFTOOL_PATH";
>> +const BPFTOOL_PATH: &str = "/usr/sbin/bpftool";
>> +
>> +/// Run a bpftool command and returns the output
>> +fn run_bpftool_command(args: &[&str]) -> std::process::Output {
>> + let mut cmd = Command::new(std::env::var(BPFTOOL_PATH_ENV).unwrap_or(BPFTOOL_PATH.to_string()));
>> + cmd.args(args);
>> + println!("Running command {:?}", cmd);
>> + cmd.output().expect("failed to execute process")
>> +}
>> +
>> +/// Simple test to make sure we can run bpftool
>> +#[test]
>> +fn run_bpftool() {
>> + let output = run_bpftool_command(&["version"]);
>> + assert!(output.status.success());
>> +}
>> diff --git a/tools/testing/selftests/bpf/bpftool_tests/src/main.rs b/tools/testing/selftests/bpf/bpftool_tests/src/main.rs
>> new file mode 100644
>> index 000000000000..6b4ffcde7406
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/bpftool_tests/src/main.rs
>> @@ -0,0 +1,3 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>> +#[cfg(test)]
>> +mod bpftool_tests;
>
> There is rust in the kernel tree already.
> Most of it is #![no_std] and the rest depend on
> rust_is_available.sh and the kernel build system.
> This rust usage doesn't fit into two existing rust categories afaics.
I haven't followed closely the introduction of Rust in the kernel
repository, so apologies if I'm incorrect. From what I understand,
#![no_std] is to avoid linking against the std-crate, which is necessary
for Rust code that needs to be compiled as part of the kernel or
modules, but is maybe not relevant for something external like a test
suite? As for rust_is_available.sh, we would need a way to determine
whether Rust is available indeed, before plugging these tests into the
Makefile for the BPF selftests.
As far as I'm aware, these would be the first selftests written in Rust
in the repo (other than for the code under rust/). I'm fine having tests
in Rust for bpftool, for what it matters. Whether we want selftests in
Rust in the kernel repo is another thing.
>
> Does it have to leave in the kernel tree?
> We have bpftool on github, maybe it can be there?
> Do you want to run bpftool tester as part of BPF CI and that's why
> you want it to be in the kernel tree?
It doesn't _have_ to be in the kernel tree, although it's a nice place
where to have it. We have bpftool on GitHub, but the CI that runs there
is triggered only when syncing the mirror to check that mirroring is not
broken, so after new patches are applied to bpf-next. If we want this on
GitHub, we would rather target the BPF CI infra.
A nice point of having it in the repo would be the ability to add tests
at the same time as we add features in bpftool, of course.
Quentin
