Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >> > > > > By switching up actual libbpf used to compile with bpftool, you are >> >> > > > > potentially introducing subtle problems that your users will be quite >> >> > > > > unhappy about, if they run into them. Let's work together to make it >> >> > > > > easier for you to package bpftool properly. We can't switch bpftool to >> >> > > > > reliably use system-wide libbpf (either static or shared, doesn't >> >> > > > > matter) because of dependency on internal functionality. >> >> > > > > >> >> > > > > >> >> > > > > [0] https://github.com/libbpf/veristat/releases/tag/v0.1 >> >> > > > >> >> > > > So how many copies of libbpf do I need for having a CO-RE toolchain? >> >> > > >> >> > > What do you mean by "CO-RE toolchain"? bpftool, veristat, retsnoop, >> >> > > etc are tools. The fact they are using statically linked libbpf >> >> > > through Git submodule is irrelevant to end users. You need one libbpf >> >> > > in the system (for those who link dynamically against libbpf), the >> >> > > rest are just tools. >> >> > > >> >> > > > >> >> > > > Will different tools have different view of the kernel because they each >> >> > > > use different private copy of libbpf with different features? >> >> > > >> >> > > That's up to tools, not libbpf. You are over pivoting on libbpf here. >> >> > > There is one view of the kernel, it depends on what features the >> >> > > kernel supports. If the tool requires some specific functionality of >> >> > > libbpf, it will update its Git submodule reference to get a version of >> >> > > libbpf that provides that feature. That's the point, an >> >> > > application/tool is in control of what kind of features it gets from >> >> > > libbpf. >> >> >> >> Since libbpf has a stable API & ABI, is it theoretically possible for >> >> bpftool, veristat, retsnoop, etc. all share the same version of libbpf? >> > >> > No, because libbpf is not just a set of APIs. Newer libbpf versions >> > support more BPF-side features, more kernel features, etc, etc. Libbpf >> > is not a typical user-space library, it is a BPF loader, and even if >> > user-visible API doesn't change, libbpf's support for various BPF-side >> > features is extended. Which is important for tools like bpftool, >> > retsnoop, veristat which rely on loading and working with BPF object >> > files. >> >> The converse of this is also true: if your system is upgraded to a new >> kernel version with new BPF features, the libbpf version should follow >> it, and all applications linked against it will automatically take >> advantage of any bugfixes regardless without having to wait for each >> application to be updated. > > No, if my application was not developed to take advantage of a new > kernel feature, newer libbpf will do nothing for me. If my application > wants to support that feature, I'll update my application and > correspondingly update libbpf embedded in it. If my application is > affected by some bug fix, I'll update libbpf even faster than distros > will get to it. You may do that, but you're also someone who is following the development of libbpf closely and pay attention to when bugs appear. Not all applications developers have the same vigilance for all the libraries they rely on. Which is the reason distros generally take on the responsibility of ensuring their users receive timely library updates. > I've heard all such arguments over the last few years. They are not > convincing and my own practical experience shows irrelevance of the > above argument. I don't doubt your personal experience, I'm just objecting to you dismissing other points of view just because you haven't experienced them yourself. >> Libbpf is really no different from any other library here, and I really >> don't get why you keep insisting it's "special"... > > It's special in the sense that it provides two sets of APIs -- for > user-space (typical libraries) and BPF object files. Besides that, for > BPF-side it's not even a set of APIs (headers, helpers, etc), it also > provides some set of functionality that can improve or be extended > over time. E.g., libbpf used to not support non-inlined BPF > subprograms, and then it started supporting them. In terms of API/ABI > -- nothing changed. Yet the change is very important. Lots of libraries do that. File format libraries support new format features without changing their API, networking libraries support new protocol features, etc. So again, libbpf is not special in this respect. > Now, I build a tool that is using libbpf and some BPF functionality, > e.g., retsnoop. Libbpf just got SEC("ksyscall") support. Retsnoop > wants to take advantage of it. I just go and use SEC("ksyscall") > programs in .bpf.c files that are embedded inside retsnoop. > I don't have to *and don't want to* do feature detection of whether a > particular libbpf version that happens to be installed/packaged on the > system supports this version. I *know* it does, because I control it, > through a submodule. That's what I care about. Right, so just require a minimum version of the library where the API you want to use is available. That is pretty standard and distros deal with this all the time. This is not an argument for static linking or vendoring... > Whether some distro insists on libbpf being shared across any > libbpf-using application or not is none of my concern. Libbpf is an > implementation detail of my application (retsnoop), it's not for the > packager to decide how I develop and structure my tool. Right, well, you don't *have* to be cooperative with the wider ecosystem, of course. Just as packagers don't have to follow your recommendations if they have good reasons not to. I believe we've had this discussion before, and I don't think we're going to agree this time around either, so let's not waste any more virtual ink on rehashing it :) -Toke
