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?
