Re: [PATCHv3 iproute2-next 0/5] iproute2: add libbpf support

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Wed, Nov 4, 2020 at 3:05 PM Edward Cree <ecree@solarflare.com> wrote:
>
> On 04/11/2020 22:10, Alexei Starovoitov wrote:
> > On Wed, Nov 4, 2020 at 1:16 PM Edward Cree <ecree@solarflare.com> 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.

I'll just quote myself here for your convenience.

  Submodule is a way that I know of to make this better for end users.
  If there are other ways to pull this off with shared library use, I'm
  all for it, it will save the security angle that distros are arguing
  for. E.g., if distributions will always have the latest libbpf
  available almost as soon as it's cut upstream *and* new iproute2
  versions enforce the latest libbpf when they are packaged/released,
  then this might work equivalently for end users. If Linux distros
  would be willing to do this faithfully and promptly, I have no
  objections whatsoever. Because all that matters is BPF end user
  experience, as Daniel explained above.

No one replied to that, unfortunately.


> > 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