> My commits sets BPFTOOL to bpftool since otherwise, the feature check > would fail, as BPFTOOL wouldn't be defined, since it is not passed to > the feature detection make call.
Sorry I don't understand the issue, why not simply rename the variable that you introduced in tools/build/feature/Makefile at the same time, as well? That should solve it, no? This way you don't have to export it from the rtla Makefiles. Or am I missing something? 2025-03-25 16:09 UTC+0100 ~ Tomas Glozar <tglo...@redhat.com> > út 25. 3. 2025 v 15:59 odesílatel Tomas Glozar <tglo...@redhat.com> napsal: >> Shouldn't the selftests always test the in-tree bpftool instead of the >> system one? Let's say there is a stray BPFTOOL environmental variable. >> In that case, the tests will give incorrect, possibly false negative >> results, if the user is expecting selftests to test what is in the >> kernel tree. If it is intended to also be able to test with another I think this was the intent. >> version of bpftool, we can work around the problem by removing the >> BPFTOOL definition from tools/scripts/Makefile.include and exporting >> it from the rtla Makefiles instead, to make sure the feature tests see >> it. The problem with that is, obviously, that future users of the >> bpftool feature check would have to do the same, or they would always >> fail, unless the user sets BPFTOOL as an environment variable >> themselves. > > Or the selftests and other users could use another variable, like > BPFTOOL_TEST or BPFTOOL_INTERNAL. Not sure what you BPF folks think > about that. I believe assuming BPFTOOL refers to the system bpftool > (just like it does for all the other tools) is quite reasonable. The variable name needs to change either for rtla + probe, or for all BPF utilities relying on it, indeed. As far as I can see, this is the sched_ext and runqslower utilities as well as the selftests for bpf, sched_ext, and hid. I'd argue that the variable has been in use in the Makefiles for these tools and selftests for a while, and renaming it might produce errors for anyone already using it to pass a specfic version of bpftool to try. > The reason why I opted to use the system bpftool is that bpftool > itself has a lot of dependencies Note: Not that many dependencies, most of them are optional. For bootstrap bpftool we pass -lelf, -lz, sometimes -lzstd. Quentin
