2023-11-21 16:42 UTC+0000 ~ Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > 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. True. I've been hoping the tests would look easy enough that devs could update them without being particularly versed in Rust, but this is probably wishful thinking, and prone to getting bugs in the tests. I don't have a good proposal to address this, so I agree, this is probably not a reasonable requirement. > If tester and bpftool are not sync then they can be in separate repos. Makes sense. I'd like to have the tests in the same repo, but for this time, let's focus on getting these Rust tests added to the BPF CI infra instead, if there's no easy way to switch to a more consensual language. Manu, thoughts? Quentin
