Daniel Borkmann [off-list ref] 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