On Mon, Nov 16, 2020 at 08:38:15PM -0700, David Ahern wrote: > > As for the bigger problem, trying to force user space components to > constantly chase latest and greatest S/W versions is not the right answer. Your own nexthop enhancements in the kernel code follow 1-1 with iproute2 changes. So the users do chase the latest kernel and the latest iproute2 if they want the networking feature. Yet you're arguing that for bpf features they shouldn't have such expectations with iproute2 which will not support the latest kernel bpf features. I sense a lot of bias here. > The crux of the problem here is loading bpf object files and what will > most likely be a never ending stream of enhancements that impact the > proper loading of them. Please stop this misinformation spread. Multiple people explained numerous times that libbpf takes care of backward compatibility. > That said, the legacy bpf code in iproute2 has created some > expectations, and iproute2 can not simply remove existing capabilities. It certainly can remove them by moving to libbpf. > iproute2 is a networking configuration tool, not a bpf management tool. > Hangbin’s approach gives full flexibility to those who roll their own > and for distributions who value stability, it allows iproute2 to use > latest and greatest libbpf for those who want to chase the pot of gold > at the end of the rainbow, or they can choose stability with an OS > distro’s libbpf or legacy bpf. I believe this is the right compromise at > this point in time. In other words you're saying that upstream iproute2 is a kitchen sink of untested combinations of libraries and distros suppose to do a ton of extra work to provide their users a quality iproute2.
