On Mon, Nov 16, 2020 at 03:54:46PM +0100, Jesper Dangaard Brouer wrote: > > Thus, IMHO we MUST move forward and get started with converting > iproute2 to libbpf, and start on the work to deprecate the build in > BPF-ELF-loader. I would prefer ripping out the BPF-ELF-loader and > replace it with libbpf that handle the older binary elf-map layout, but > I do understand if you want to keep this around. (at least for the next > couple of releases). I don't understand why legacy code has to be around. Having the legacy code and an option to build tc without libbpf creates backward compatibility risk to tc users: Newer tc may not load bpf progs that older tc did. > I actually fear that it will be a bad user experience, when we start to > have multiple userspace tools that load BPF, but each is compiled and > statically linked with it own version of libbpf (with git submodule an > increasing number of tools will have more variations!). So far people either freeze bpftool that they use to load progs or they use libbpf directly in their applications. Any other way means that the application behavior will be unpredictable. If a company built a bpf-based product and wants to distibute such product as a package it needs a way to specify this dependency in pkg config. 'tc -V' is not something that can be put in a spec. The main iproute2 version can be used as a dependency, but it's meaningless when presence of libbpf and its version is not strictly derived from iproute2 spec. The users should be able to write in their spec: BuildRequires: iproute-tc >= 5.10 and be confident that tc will load the prog they've developed and tested. > I actually thinks it makes sense to have iproute2 require a specific > libbpf version, and also to move this version requirement forward, as > the kernel evolves features that gets added into libbpf. +1
