On Thu, Nov 12, 2020 at 4:35 PM Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 13 Nov 2020 00:20:52 +0100 > Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > > On 11/12/20 11:36 PM, Toke Høiland-Jørgensen wrote: > > > Daniel Borkmann <daniel@xxxxxxxxxxxxx> writes: > > > > > >>> Besides, for the entire history of BPF support in iproute2 so far, the > > >>> benefit has come from all the features that libbpf has just started > > >>> automatically supporting on load (BTF, etc), so users would have > > >>> benefited from automatic library updates had it *not* been vendored in. > > >> > > >> Not really. What you imply here is that we're living in a perfect > > >> world and that all distros follow suite and i) add libbpf dependency > > >> to their official iproute2 package, ii) upgrade iproute2 package along > > >> with new kernel releases and iii) upgrade libbpf along with it so that > > >> users are able to develop BPF programs against the feature set that > > >> the kernel offers (as intended). These are a lot of moving parts to > > >> get right, and as I pointed out earlier in the conversation, it took > > >> major distros 2 years to get their act together to officially include > > >> bpftool as a package - I'm not making this up, and this sort of pace > > >> is simply not sustainable. It's also not clear whether distros will > > >> get point iii) correct. > > > > > > I totally get that you've been frustrated with the distro adoption and > > > packaging of BPF-related tools. And rightfully so. I just don't think > > > that the answer to this is to try to work around distros, but rather to > > > work with them to get things right. > > > > > > I'm quite happy to take a shot at getting a cross-distro effort going in > > > this space; really, having well-supported BPF tooling ought to be in > > > everyone's interest! > > > > Thanks, yes, that is worth a push either way! There is still a long tail > > of distros that are not considered major and until they all catch up with > > points i)-iii) it might take a much longer time until this becomes really > > ubiquitous with iproute2 for users of the libbpf loader. Its that this > > frustrating user experience could be avoided altogether. iproute2 is > > shipped and run also on small / embedded devices hence it tries to have > > external dependencies reduced to a bare minimum (well, except that libmnl > > detour, but it's not a mandatory dependency). If I were a user and would > > rely on the loader for my progs to be installed I'd probably end up > > compiling my own version of iproute2 linked with libbpf to move forward > > instead of being blocked on distro to catch up, but its an additional > > hassle for shipping SW instead of just having it all pre-installed when > > built-in given it otherwise comes with the base distro already. But then > > my question is what is planned here as deprecation process for the built-in > > lib/bpf.c code? I presume we'll remove it eventually to move on? > > Perf has a similar problem and it made it into most distributions because it is > a valuable tool. Maybe there is some lessons learned that could apply here. Indeed. Please read tools/perf/Documentation/Build.txt and realize that perf binary _statically_ links libperf library.
