On Tue, Nov 17, 2020 at 11:19:33AM +0800, Hangbin Liu wrote: > On Mon, Nov 16, 2020 at 06:37:57PM -0800, Alexei Starovoitov wrote: > > 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. > > If a distro choose to compile iproute2 with libbpf, I don't think they will > compile iproute2 without libbpf in new version. So yum/apt-get update from > official source doesn't like a problem. > > Unless a user choose to use a self build iproute2 version. Then the self build > version may also don't have other supports, like libelf, libnml, libcap etc. > > > > > > 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. > > The current patch does have a libbpf version check, it need at least libbpf > 0.1.0. So if a distro starts to build iproute2 based on libbpf, there will > have a dependence. The rule could be added to rpm spec file, or what else > the distro choose. That's the distro compiler's work. > > Unless you want to say a company built a bpf-based product, they only > add iproute2 version dependence(let's say some distros has iproute2 5.12 with > libbpf supported), and somehow forgot add libbpf version dependence check > and distro check. At the same time a user run the product on a distro without > libbpf compiled on iproute2 5.12. That do will cause problem. right. You've answered Ed's question: > But if libbpf is dynamically linked, they can put > Requires: libbpf >= 0.3.0 > Requires: iproute-tc >= 5.10 > and get the dependency behaviour they need. No? It is a problem because >= 5.10 cannot capture legacy vs libbpf. > But if I'm the user, I will think the company is not professional for bpf > product that they even do not know libbpf is needed... > > So my opinion: for end user, the distro should take care of libbpf and > iproute2 version control. For bpf company, they should take care if libbpf > is used by the iproute2 and what distros they support. So you're saying that bpf community shouldn't care about their users. The distros suppose to step forward and provide proper bpf support in tools like iproute2? In other words iproute2 upstream doesn't care about shipping quality product. It's distros job now. Thanks, but no. iproute2 should stay with legacy obsolete prog loader and the users should switch to bpftool + iproute2 combination. bpftool for loading progs and iproute2 for networking configs.
