On Wed, Apr 19, 2023 at 3:55 AM Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > 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. I'm not sure what the proposal is, but I'll delegate to Arnaldo. > > > 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. Even though libbpf source is developed in kernel repo, it's not tied to specific kernel. So any kernel backports have no relevance to libbpf itself. It's yet another reason to switch to Github mirror. Github is merging libbpf-related fixes from both bpf and bpf-next trees during sync, and is meant to always be the latest and best version with all fixes included. I won't claim anything for perf, maybe Arnaldo can clarify, but I suspect that perf is also meant to be relatively independent from specific kernel and work on wide variety of kernels. As for stable branches. For libbpf, we don't have it because we didn't need it yet. We did have bug fix patch releases that seem to be working out fine, though. > > Thanks, > Shung-Hsi > > > -Toke > >
