Daniel Borkmann <dan...@iogearbox.net> writes: > Back in the days when developing lib/bpf.c, it was explicitly done as > built-in for iproute2 so that it doesn't take years for users to > actually get to the point where they can realistically make use of it. > If we were to extend the internal lib/bpf.c to similar feature state > as libbpf today, how is that different in the bigger picture compared > to sync or submodule... so far noone complained about lib/bpf.c.
Except that this whole effort started because lib/bpf.c is slowly bitrotting into oblivion? If all the tools are dynamically linked against libbpf, that's only one package the distros have to keep up-to-date instead of a whole list of tools. How does that make things *worse*? -Toke
