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.
