Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
From: Toke Høiland-Jørgensen <hidden>
Date: 2020-02-04 08:25:55
Also in:
bpf
Andrii Nakryiko [off-list ref] writes:
On Mon, Feb 3, 2020 at 8:53 PM David Ahern [off-list ref] wrote:quoted
On 2/3/20 8:41 PM, Andrii Nakryiko wrote:quoted
On Mon, Feb 3, 2020 at 5:46 PM David Ahern [off-list ref] wrote:quoted
On 2/3/20 5:56 PM, Andrii Nakryiko wrote:quoted
Great! Just to disambiguate and make sure we are in agreement, my hope here is that iproute2 can completely delegate to libbpf all the ELFiproute2 needs to compile and continue working as is when libbpf is not available. e.g., add check in configure to define HAVE_LIBBPF and move the existing code and move under else branch.Wouldn't it be better to statically compile against libbpf in this case and get rid a lot of BPF-related code and simplify the rest of it? This can be easily done by using libbpf through submodule, the same way as BCC and pahole do it.iproute2 compiles today and runs on older distributions and older distributions with newer kernels. That needs to hold true after the move to libbpf.And by statically compiling against libbpf, checked out as a submodule, that will still hold true, wouldn't it? Or there is some complications I'm missing? Libbpf is designed to handle old kernels with no problems.
My plan was to use the same configure test I'm using for xdp-tools (where I in turn copied the structure of the configure script from iproute2): https://github.com/xdp-project/xdp-tools/blob/master/configure#L59 This will look for a system libbpf install and compile against it if it is compatible, and otherwise fall back to a statically linking against a git submodule. We'll need to double-check that this will work on everything currently supported by iproute2, and fix libbpf if there are any issues with that. Not that I foresee any, but you never know :) -Toke