Thanks for sharing! I though I'd expands on what you said to draw a clearer picture of the challenges. On Thu, Apr 13, 2023 at 01:00:20PM +0200, Toke Høiland-Jørgensen wrote: > Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> writes: > > > A side note: if we want all userspace visible libbpf to have a coherent > > version, perf needs to use the shared libbpf library as well (either > > autodetected or forced with LIBBPF_DYNAMIC=1 like Fedora[4]). But having to > > backport patches to kernel source to keep up with userspace package (libbpf) > > changes could be a pain. Here some more context for completeness. Kernel source changes are published at a much slower pace than userspace. When an application in the kernel source (e.g. perf) depends on the userspace library, it's kind of like trying to catchup a car on a bike, which is doable, as evident by the plethora of userspace libraries perf already depends on. While I don't having experience maintaining perf, judging by tools/perf/Makefile.config that does not seem like an easy feat. For perf to use libbpf in kernel would mean that it's just depending on something that moves at the same pace. That said, maybe perf won't need additional backport to keep up with libbpf as long as we keep it within that same major version (and disable deprecation warning)? @Andrii Now that We've got pass libbpf 1.0 it seems like a good time to reconsider. > So basically, this here is the reason we're building libbpf from the > kernel tree for the RHEL package: If we use the github version we'd need > to juggle two different versions of libbpf, one for the in-kernel-tree > users (perf as you mention, but also the BPF selftests), and one for the > userspace packages. Also, having libbpf in the kernel tree means we can > just backport patches to it along with the BPF-related kernel patches > (we do quite extensive BPF backports for each RHEL version). > Finally, building from the kernel tree means we can use the existing > kernel-related procedures for any out of order hotfixes (since AFAIK none > of the github repositories have any concept of stable branches that > receive fixes). +1 Got something similar in place as well and being able to stick with existing procedure is appealing. > YMMV of course, but figured I'd share our reasoning. To be clear, > building from the kernel tree is not without its own pain points (mostly > related to how the build scripts are structured for our kernel builds). > We've discussed moving to the github version of libbpf multiple times, > but every time we've concluded that it would be more, not less, painful > than having the kernel tree be the single source of truth. We package maintainer are certainly quite hard to please :) Just having an individual package easy to work with is not enough, we want it to be easier for most packages before jumping on the bandwagon, which is why this email ended up talking about perf despite it started as a discussion on packaging libbpf and bpftool. I suppose the mileage depends on the build system & scripts in use and how much backporting is done; the more kernel backporting (along with more established processes in place), the more painful it'd be to move to the GitHub version. My gut feeling is that SLES do less backporting compared to RHEL when it comes to BPF, and that probably placed us closer to the middle ground. Thanks, Shung-Hsi > -Toke >
