On 04/11/2020 22:10, Alexei Starovoitov wrote: > On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <ecree@xxxxxxxxxxxxxx> wrote: >> On 04/11/2020 03:11, Alexei Starovoitov wrote: >>> The user will do 'tc -V'. Does version mean anything from bpf loading pov? >>> It's not. The user will do "ldd `which tc`" and then what? >> Is it beyond the wit of man for 'tc -V' to output somethingabout >> libbpf version? >> Other libraries seem to solve these problems all the time, I >> haven't seen anyone explain what makes libbpf so special that it >> has to be different. > slow vger? Please see Daniel and Andrii detailed explanations. Nah, I've seen that subthread(vger is fine). I felt that subthread was missing this point about -V which is why I replied where it was brought up. Daniel and Andrii have only explained why users will want to have an up-to-date libbpf, they (and you) haven't connected it to any argument about why static linking is the way to achieve that. > libbpf is not your traditional library. This has only been asserted, not explained. I'm fully willing to entertain the possibility that libbpf is indeed special. But if you want to win people over, you'll need to explain *why* it's special. "Look at bfd and think why" is not enough, be more explicit. AIUI the API between iproute2 and libbpf isn't changing, all that's happening is that libbpf is gaining new capabilities in things that are totally transparent to iproute2 (e.g. BTF fixups). So the reasonable thing for users to expect is "I need new BPF features, I'll upgrade my libbpf", and with dynamic linking that works fine whether they upgrade iproute2 too or not. This narrative is, on the face of it, just as plausible as "I'm getting an error from iproute2, I'll upgrade that". And if distros decide that that's a common enough mistake to matter, then they can make the newer iproute2 package depend on a newer libbpf package, and apt or yum or whatever will automagically DTRT. Whereas if you tightly couple them from the start, distros can't then go the other way if it turns out you made the wrong choice. (What if someone can't use the latest iproute2 release because it has a regression bug that breaks their use-case, but they need the latest libbpf for one of your shiny new features?) Don't get me wrong, I'd love a world in which static linking was the norm and we all rebuilt our binaries locally every time we upgraded a piece. But that's not the world we live in, and consistency *within* a distro matters too... -ed
