On Mon, Nov 27, 2023 at 9:07 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: > > 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. Can we use veristat to load BPF object files? we might need some option to auto-pin programs in some directory or something to keep them live long enough, I suppose, but it's totally in our control. > > Manu, did you have other reasons in mind?
