2023-11-21 19:50 UTC+0000 ~ Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> > On Tue, Nov 21, 2023 at 8:42 AM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: >> >> On Tue, Nov 21, 2023 at 8:26 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: >>> >>>> >>>> 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. >> >> Sounds nice in theory, but in practice that would mean that >> every bpftool developer adding a new feature would need to learn rust >> to add a corresponding test? >> I suspect devs might object to such a requirement. >> If tester and bpftool are not sync then they can be in separate repos. > > I'm also wondering what Rust and libbpf-rs dependency adds here? It > feels like bash+jq or Python script should be able to "drive" bpftool > CLI and validate output, no? As I understand, one advantage is to get an easy way to tap into libbpf's functions to load the objects we need in order to test the different bpftool features. There are a number of program/map types that we just cannot load with bpftool at this time, so we need to set up the objects we need with another loader. Libbpf-rs allows to do that, and the "cargo test" infra seems like a convenient way to focus on the tests only. Bash+jq wouldn't allow to load objects unsupported by bpftool, for example. Manu, did you have other reasons in mind?
