On Fri, Nov 6, 2020 at 4:41 PM Stephen Hemminger
[off-list ref] wrote:

On Fri, 6 Nov 2020 15:30:38 -0800
Andrii Nakryiko [off-list ref] wrote:

quoted

On Fri, Nov 6, 2020 at 3:25 PM Stephen Hemminger
[off-list ref] wrote:

quoted

On Fri, 6 Nov 2020 13:04:16 -0800
Alexei Starovoitov [off-list ref] wrote:

quoted

On Fri, Nov 6, 2020 at 12:58 PM Andrii Nakryiko
[off-list ref] wrote:

quoted

On Fri, Nov 6, 2020 at 12:44 AM Jiri Benc [off-list ref] wrote:

quoted

On Thu, 5 Nov 2020 12:19:00 -0800, Andrii Nakryiko wrote:

quoted

I'll just quote myself here for your convenience.

Sorry, I missed your original email for some reason.

quoted

  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.

That's basically what we already do, for both Fedora and RHEL.

Of course, it follows the distro release cycle, i.e. no version
upgrades - or very limited ones - during lifetime of a particular
release. But that would not be different if libbpf was bundled in
individual projects.

Alright. Hopefully this would be sufficient in practice.

I think bumping the minimal version of libbpf with every iproute2 release
is necessary as well.
Today iproute2-next should require 0.2.0. The cycle after it should be 0.3.0
and so on.
This way at least some correlation between iproute2 and libbpf will be
established.
Otherwise it's a mess of versions and functionality from user point of view.

As long as iproute2 6.0 and libbpf 0.11.0 continues to work on older kernel
(like oldest living LTS 4.19 in 2023?); then it is fine.

Just don't want libbpf to cause visible breakage for users.

libbpf CI validates a bunch of selftests on 4.9 kernel, see [0]. It
should work on even older ones. Not all BPF programs would load and be
verified successfully, but libbpf itself should work regardless.

  [0] https://travis-ci.com/github/libbpf/libbpf/jobs/429362146

Look at the dates in my note, are you willing to promise that compatibility
in future versions.

I don't understand why after so many emails in this thread it's still
not clear that backwards compatibility is in libbpf's DNA. And no one
can even point out where and when exactly libbpf even had a problem
with backwards compatibility in the first place! Yet, all of this
insinuation of libbpf API instability...

So for the last time (hopefully): yes!

We managed to do that for at least 2 last years, why would we suddenly
break this?