Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > On Mon, Feb 3, 2020 at 8:53 PM David Ahern <dsahern@xxxxxxxxx> wrote: >> >> On 2/3/20 8:41 PM, Andrii Nakryiko wrote: >> > On Mon, Feb 3, 2020 at 5:46 PM David Ahern <dsahern@xxxxxxxxx> wrote: >> >> >> >> On 2/3/20 5:56 PM, Andrii Nakryiko wrote: >> >>> Great! Just to disambiguate and make sure we are in agreement, my hope >> >>> here is that iproute2 can completely delegate to libbpf all the ELF >> >>> >> >> >> >> iproute2 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
