On Fri, Jan 19, 2024 at 3:35 PM Andrii Nakryiko andrii.nakryiko@gmail.com wrote:
On Fri, Jan 19, 2024 at 3:13 PM Vincent Li vincent.mc.li@gmail.com wrote:
On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Fri, Jan 19, 2024 at 7:00 AM Vincent Li vincent.mc.li@gmail.com wrote:
On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman eddyz87@gmail.com wrote:
On Fri, 2024-01-19 at 16:04 +0800, Shung-Hsi Yu wrote:
[...]
Final goal would be have BPF selftests compiled and test against our own kernel, without having to come up with a specific kernel flavor that is used to build and run the selftest. For v5.14 and v5.19-based kernel it works: compilation is successful and I was able to run the verifier tests. (Did not try running the other tests though)
You mean ./test_verifier binary, right? A lot of tests had been moved from ./test_verifier to ./test_progs since.
> As far as I understand, selftests are supposed to be built and run > using specific configuration, here is how config for x86 CI is prepared: > > ./scripts/kconfig/merge_config.sh \ > ./tools/testing/selftests/bpf/config \ > ./tools/testing/selftests/bpf/config.vm \ > ./tools/testing/selftests/bpf/config.x86_64 > > (root is kernel source). > I'm not sure if other configurations are supposed to be supported.
Would it make sense to have makefile target that builds/runs a smaller subset of general, config-agnostic selftests that tests the core feature (e.g. verifier + instruction set)?
In ideal world I'd say that ./test_progs should include/exclude tests conditioned on current configuration, but I don't know how much work would it be to adapt build system for this.
I would also suggest skipping building the specific bpf test code when a specific CONFIG is removed, sometimes I only want to test some bpf selftests code I am interested in :)
I don't think we should be complicating bpf selftests to test configurations with reduced kconfig. bpf/config.* is what we target in bpf CI and we expect developers do the same amount of testing before they send patches.
Totally understand that from the kernel bpf developer perspective. I am a bpf user learning how to write a bpf program from selftests, but I guess there is another way to learn, selftests is not for teaching bpf users, no need to complicate.
Try libbpf-bootstrap ([0]) as a simple setup to play with new BPF features. minimal or bootstrap examples are usually good starting points.
Thanks! I am aware of libbpf-bootstrap, I am on an old centos 8 distro which often miss linux headers that some selftests happens to require, especially the ones that are not using vmlinux.h, when a bpf kernel developer submit patches and selftests that I am interested in, I want to run that selftests and learn the new feature, and then probably port the new useful selftests code to a real use case bpf program. I often run into other selftests compiling errors when I want to selftest the new feature I am interested in. Anyway, it is my build environment problem, not selftests.