David Ahern <dsahern@xxxxxxxxx> writes: > On 2/4/20 3:35 PM, Toke Høiland-Jørgensen wrote: >> >>> Most likely, making iproute2 use libbpf statically is going to be >>> challenging and I am not sure it is the right thing to do (unless the >>> user is building a static version of iproute2 commands). >> >> Linking dynamically would imply a new dependency. I'm not necessarily >> against that, but would it be acceptable from your PoV? And if so, >> should we keep the current internal BPF code for when libbpf is not >> available, or would it be acceptable to not be able to load BPF programs >> if libbpf is not present (similar to how the libelf dependency works >> today)? > > iproute2 recently gained the libmnl dependency for extack. Seems like > libbpf falls into the similar category. > >> >>> 2. git submodules can be a PITA to deal with (e.g., jumping between >>> branches and versions), so there needs to be a good reason for it. >> >> Yes, totally with you on that. Another option could be to just copy the >> files into the iproute2 tree, and update them the same way the kernel >> headers are? Or maybe doing fancy things like this: >> https://github.com/apenwarr/git-subtrac > > kernel uapi is a totally different reason to import the headers. bpf > functionality is an add-on. > > I would like to see iproute2 work with libbpf. Given libbpf's current > status and availability across OS'es that is going to be a challenge for > a lot of OS'es which is why I suggested the HAVE_LIBBPF check falls back > to existing code if libbpf is not installed. Sure, can do. -Toke
