Hello Quentin, Venkat, Saket, Thanks for looking into this.
út 25. 3. 2025 v 13:12 odesílatel Quentin Monnet <q...@kernel.org> napsal: > If you talk about tools/tracing/rtla/Makefile failing to locate bpftool, > it's another matter. As far as I understand, the RTLA Makefile assumes > that bpftool is available from $PATH, this is why the commit introduced > a probe in tools/build/feature: to ensure that bpftool is installed and > available. So here again, I don't see the motivation for changing the > path to the binary (And how do you know it's /usr/sbin/bpftool anyway? > Some users have it under /usr/local/sbin/, for example). If the intent > were to compile a bootstrap bpftool to make sure that it's available > instead then it should replicate what other BPF utilities or selftests > do, and get rid of the probe. But the commit description for > 8a635c3856dd indicates that RTLA folks prefer not to compile bpftool and > rely on it being installed. Yes, that is correct. The reason why I opted to use the system bpftool is that bpftool itself has a lot of dependencies, and they would have to be available at the time of building RTLA. Since RTLA only requires basic bpftool skeleton generation, and the only "special" feature it uses is CO-RE which is already quite old now, I don't expect the build to fail with system bpftool, so I chose to use that to make both the build dependencies and the RTLA Makefiles simpler. 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. I observed we are doing the same for Clang and the LLVM toolchain in tools/scripts/Makefile.include; obviously, there is no problem there, since neither of these are in-kernel. 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 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. Tomas
