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?
