All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@google.com>,
	Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
Date: Mon, 24 May 2021 14:26:19 -0700	[thread overview]
Message-ID: <CAEf4BzadPCOboLov7dbVAQAcQtNj+x4CP7pKutXxo90q7oUuLQ@mail.gmail.com> (raw)
In-Reply-To: <87a6ojzwdi.fsf@toke.dk>

On Mon, May 24, 2021 at 1:53 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>
> > On Sun, May 23, 2021 at 11:36 PM John Fastabend
> > <john.fastabend@gmail.com> wrote:
> >>
> >> Andrii Nakryiko wrote:
> >> > Implement error reporting changes discussed in "Libbpf: the road to v1.0"
> >> > ([0]) document.
> >> >
> >> > Libbpf gets a new API, libbpf_set_strict_mode() which accepts a set of flags
> >> > that turn on a set of libbpf 1.0 changes, that might be potentially breaking.
> >> > It's possible to opt-in into all current and future 1.0 features by specifying
> >> > LIBBPF_STRICT_ALL flag.
> >> >
> >> > When some of the 1.0 "features" are requested, libbpf APIs might behave
> >> > differently. In this patch set a first set of changes are implemented, all
> >> > related to the way libbpf returns errors. See individual patches for details.
> >> >
> >> > Patch #1 adds a no-op libbpf_set_strict_mode() functionality to enable
> >> > updating selftests.
> >> >
> >> > Patch #2 gets rid of all the bad code patterns that will break in libbpf 1.0
> >> > (exact -1 comparison for low-level APIs, direct IS_ERR() macro usage to check
> >> > pointer-returning APIs for error, etc). These changes make selftest work in
> >> > both legacy and 1.0 libbpf modes. Selftests also opt-in into 100% libbpf 1.0
> >> > mode to automatically gain all the subsequent changes, which will come in
> >> > follow up patches.
> >> >
> >> > Patch #3 streamlines error reporting for low-level APIs wrapping bpf() syscall.
> >> >
> >> > Patch #4 streamlines errors for all the rest APIs.
> >> >
> >> > Patch #5 ensures that BPF skeletons propagate errors properly as well, as
> >> > currently on error some APIs will return NULL with no way of checking exact
> >> > error code.
> >> >
> >> >   [0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an11_iaRuec6U-ZESZ54nNTY
> >> >
> >> > Andrii Nakryiko (5):
> >> >   libbpf: add libbpf_set_strict_mode() API to turn on libbpf 1.0
> >> >     behaviors
> >> >   selftests/bpf: turn on libbpf 1.0 mode and fix all IS_ERR checks
> >> >   libbpf: streamline error reporting for low-level APIs
> >> >   libbpf: streamline error reporting for high-level APIs
> >> >   bpftool: set errno on skeleton failures and propagate errors
> >> >
> >>
> >> LGTM for the series,
> >>
> >> Acked-by: John Fastabend <john.fastabend@gmail.com>
> >
> > Thanks, John!
> >
> > Toke, Stanislav, you cared about these aspects of libbpf 1.0 (by
> > commenting on the doc itself), do you mind also taking a brief look
> > and letting me know if this works for your use cases? Thanks!
>
> Changes LGTM:
>
> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> As a side note, the series seems to have been chopped up into individual
> emails with no threading; was a bit weird that I had to go hunting for
> the individual patches in my mailbox...
>

That's my bad, I messed up and sent them individually and probably
that's why they weren't threaded properly.

  reply	other threads:[~2021-05-24 21:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 23:42 [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0 Andrii Nakryiko
2021-05-24  6:36 ` John Fastabend
2021-05-24 19:18   ` Andrii Nakryiko
2021-05-24 20:35     ` Stanislav Fomichev
2021-05-24 21:25       ` Andrii Nakryiko
2021-05-24 20:53     ` Toke Høiland-Jørgensen
2021-05-24 21:26       ` Andrii Nakryiko [this message]
2021-05-24 21:34         ` Toke Høiland-Jørgensen
2021-05-24 21:46           ` Andrii Nakryiko
2021-05-24 22:19             ` Toke Høiland-Jørgensen
2021-05-25  0:06               ` 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=CAEf4BzadPCOboLov7dbVAQAcQtNj+x4CP7pKutXxo90q7oUuLQ@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.