On Fri, Jan 19, 2024 at 2:26 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Jan 19, 2024 at 7:00 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote: > > > > On Fri, Jan 19, 2024 at 4:23 AM Eduard Zingerman <eddyz87@xxxxxxxxx> 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.
