Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup

Alexei Starovoitov
2019-11-01T22:09:03Z

On Fri, Nov 1, 2019 at 2:41 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> >> The only concern with this is that without a flow of bugfixes into the
> >> 'bpf' tree (and stable), users may end up with buggy versions of libbpf.
> >> Which is in no one's interest. So how do we avoid that?
> >
> > As I explained earlier. There is no 'bpf' tree for libbpf. It always
> > moves forward.
>
> Yes, you did. And I was just pointing out that this means that there
> will be no bug fixes in older versions. So the only way to update is to
> move to an entirely new version of libbpf, including updating all the
> headers in /usr/include. And when that is not feasible, then the only
> choice left is to ship a buggy libbpf... Unless you have a third option
> I'm missing?

I'm not seeing the problem still.
Say there is a bug in installed libbpf package.
A bunch of services are using it as libbpf.so
The admin upgrades libbpf package. New libbpf.so is installed
and services should continue work as-is, since we're preserving
api binary compatibility.
Now if you're a developer you install libbpf-devel and the first thing
you'll hit is that /usr/include is so old that it doesn't have basic things
to start writing bpf progs. So recent linux-api-headers package
would have to be installed.
You keep developing stuff. Few month passes by. New libbpf is released.
At the current pace of the development one release contains
a bunch of features and a bunch of fixes.
If you're upgrading it you'd need to refresh api-headers too.
So where is the problem?

Of course there is an option to branch existing libbpf releases, but let's
cross that bridge when we actually need to do that.