bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: "Jiri Olsa" <jolsa@redhat.com>,
	"Björn Töpel" <bjorn.topel@gmail.com>,
	"Magnus Karlsson" <magnus.karlsson@gmail.com>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Björn Töpel" <bjorn.topel@intel.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Network Development" <netdev@vger.kernel.org>,
	"Jonathan Lemon" <jonathan.lemon@gmail.com>,
	bpf <bpf@vger.kernel.org>,
	degeneloy@gmail.com, "John Fastabend" <john.fastabend@gmail.com>
Subject: Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup
Date: Fri, 1 Nov 2019 15:08:47 -0700	[thread overview]
Message-ID: <CAADnVQL8XT1ejAxzaV2TZHu8fhyYZ6nKSg1mtzX33ZSooar27Q@mail.gmail.com> (raw)
In-Reply-To: <878sozmfzk.fsf@toke.dk>

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.

  reply	other threads:[~2019-11-01 22:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25  9:17 [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup Magnus Karlsson
2019-10-25 19:30 ` Jonathan Lemon
2019-10-29  3:27 ` Alexei Starovoitov
2019-10-30 13:33 ` Toke Høiland-Jørgensen
2019-10-31  7:17   ` Magnus Karlsson
2019-10-31  8:02     ` Björn Töpel
2019-10-31  8:17       ` Magnus Karlsson
2019-10-31  9:50         ` Toke Høiland-Jørgensen
2019-10-31 14:00       ` Alexei Starovoitov
2019-10-31 14:13         ` Toke Høiland-Jørgensen
2019-10-31 14:17           ` Alexei Starovoitov
2019-10-31 14:26             ` Toke Høiland-Jørgensen
2019-10-31 14:44               ` Alexei Starovoitov
2019-10-31 14:52                 ` Toke Høiland-Jørgensen
2019-10-31 15:17                   ` Alexei Starovoitov
2019-10-31 17:42                     ` Jiri Olsa
2019-10-31 18:19                       ` Alexei Starovoitov
2019-10-31 19:18                         ` Jiri Olsa
2019-10-31 20:39                           ` Alexei Starovoitov
2019-11-01  7:27                             ` Jiri Olsa
2019-11-01 15:51                               ` Alexei Starovoitov
2019-11-01 19:36                                 ` Toke Høiland-Jørgensen
2019-11-01 20:41                                   ` Alexei Starovoitov
2019-11-01 21:41                                     ` Toke Høiland-Jørgensen
2019-11-01 22:08                                       ` Alexei Starovoitov [this message]
2019-11-01  9:16                             ` Toke Høiland-Jørgensen
2019-11-01 14:51                               ` John Fastabend
2019-10-31 20:23                     ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAADnVQL8XT1ejAxzaV2TZHu8fhyYZ6nKSg1mtzX33ZSooar27Q@mail.gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=degeneloy@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=magnus.karlsson@gmail.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=toke@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).