All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
@ 2021-05-21 23:42 Andrii Nakryiko
  2021-05-24  6:36 ` John Fastabend
  0 siblings, 1 reply; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-21 23:42 UTC (permalink / raw)
  To: bpf, netdev, ast, daniel; +Cc: andrii, kernel-team

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

 tools/bpf/bpftool/gen.c                       |  27 +-
 tools/lib/bpf/Makefile                        |   1 +
 tools/lib/bpf/bpf.c                           | 168 ++++--
 tools/lib/bpf/bpf_prog_linfo.c                |  18 +-
 tools/lib/bpf/btf.c                           | 302 +++++-----
 tools/lib/bpf/btf_dump.c                      |  14 +-
 tools/lib/bpf/libbpf.c                        | 519 ++++++++++--------
 tools/lib/bpf/libbpf.h                        |   1 +
 tools/lib/bpf/libbpf.map                      |   5 +
 tools/lib/bpf/libbpf_errno.c                  |   7 +-
 tools/lib/bpf/libbpf_internal.h               |  53 ++
 tools/lib/bpf/libbpf_legacy.h                 |  59 ++
 tools/lib/bpf/linker.c                        |  22 +-
 tools/lib/bpf/netlink.c                       |  81 +--
 tools/lib/bpf/ringbuf.c                       |  26 +-
 tools/testing/selftests/bpf/bench.c           |   1 +
 .../selftests/bpf/benchs/bench_rename.c       |   2 +-
 .../selftests/bpf/benchs/bench_ringbufs.c     |   6 +-
 .../selftests/bpf/benchs/bench_trigger.c      |   2 +-
 .../selftests/bpf/prog_tests/attach_probe.c   |  12 +-
 .../selftests/bpf/prog_tests/bpf_iter.c       |  31 +-
 .../selftests/bpf/prog_tests/bpf_tcp_ca.c     |   8 +-
 tools/testing/selftests/bpf/prog_tests/btf.c  |  93 ++--
 .../selftests/bpf/prog_tests/btf_dump.c       |   8 +-
 .../selftests/bpf/prog_tests/btf_write.c      |   4 +-
 .../bpf/prog_tests/cg_storage_multi.c         |  84 +--
 .../bpf/prog_tests/cgroup_attach_multi.c      |   2 +-
 .../selftests/bpf/prog_tests/cgroup_link.c    |  14 +-
 .../bpf/prog_tests/cgroup_skb_sk_lookup.c     |   2 +-
 .../selftests/bpf/prog_tests/check_mtu.c      |   2 +-
 .../selftests/bpf/prog_tests/core_reloc.c     |  15 +-
 .../selftests/bpf/prog_tests/fexit_bpf2bpf.c  |  25 +-
 .../selftests/bpf/prog_tests/flow_dissector.c |   2 +-
 .../bpf/prog_tests/flow_dissector_reattach.c  |  10 +-
 .../bpf/prog_tests/get_stack_raw_tp.c         |  10 +-
 .../prog_tests/get_stackid_cannot_attach.c    |   9 +-
 .../selftests/bpf/prog_tests/hashmap.c        |   9 +-
 .../selftests/bpf/prog_tests/kfree_skb.c      |  19 +-
 .../selftests/bpf/prog_tests/ksyms_btf.c      |   3 +-
 .../selftests/bpf/prog_tests/link_pinning.c   |   7 +-
 .../selftests/bpf/prog_tests/obj_name.c       |   8 +-
 .../selftests/bpf/prog_tests/perf_branches.c  |   4 +-
 .../selftests/bpf/prog_tests/perf_buffer.c    |   2 +-
 .../bpf/prog_tests/perf_event_stackmap.c      |   3 +-
 .../selftests/bpf/prog_tests/probe_user.c     |   7 +-
 .../selftests/bpf/prog_tests/prog_run_xattr.c |   4 +-
 .../bpf/prog_tests/raw_tp_test_run.c          |   4 +-
 .../selftests/bpf/prog_tests/rdonly_maps.c    |   7 +-
 .../bpf/prog_tests/reference_tracking.c       |   2 +-
 .../selftests/bpf/prog_tests/resolve_btfids.c |   2 +-
 .../selftests/bpf/prog_tests/ringbuf_multi.c  |   2 +-
 .../bpf/prog_tests/select_reuseport.c         |  53 +-
 .../selftests/bpf/prog_tests/send_signal.c    |   3 +-
 .../selftests/bpf/prog_tests/sk_lookup.c      |   2 +-
 .../selftests/bpf/prog_tests/sock_fields.c    |  14 +-
 .../selftests/bpf/prog_tests/sockmap_basic.c  |   8 +-
 .../selftests/bpf/prog_tests/sockmap_ktls.c   |   2 +-
 .../selftests/bpf/prog_tests/sockmap_listen.c |  10 +-
 .../bpf/prog_tests/stacktrace_build_id_nmi.c  |   3 +-
 .../selftests/bpf/prog_tests/stacktrace_map.c |   2 +-
 .../bpf/prog_tests/stacktrace_map_raw_tp.c    |   5 +-
 .../bpf/prog_tests/tcp_hdr_options.c          |  15 +-
 .../selftests/bpf/prog_tests/test_overhead.c  |  12 +-
 .../bpf/prog_tests/trampoline_count.c         |  14 +-
 .../selftests/bpf/prog_tests/udp_limit.c      |   7 +-
 .../selftests/bpf/prog_tests/xdp_bpf2bpf.c    |   2 +-
 .../selftests/bpf/prog_tests/xdp_link.c       |   8 +-
 tools/testing/selftests/bpf/test_maps.c       | 168 +++---
 tools/testing/selftests/bpf/test_progs.c      |   3 +
 tools/testing/selftests/bpf/test_progs.h      |   9 +-
 .../selftests/bpf/test_tcpnotify_user.c       |   7 +-
 71 files changed, 1123 insertions(+), 952 deletions(-)
 create mode 100644 tools/lib/bpf/libbpf_legacy.h

-- 
2.30.2


^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  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
  0 siblings, 1 reply; 11+ messages in thread
From: John Fastabend @ 2021-05-24  6:36 UTC (permalink / raw)
  To: Andrii Nakryiko, bpf, netdev, ast, daniel; +Cc: andrii, kernel-team

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>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24  6:36 ` John Fastabend
@ 2021-05-24 19:18   ` Andrii Nakryiko
  2021-05-24 20:35     ` Stanislav Fomichev
  2021-05-24 20:53     ` Toke Høiland-Jørgensen
  0 siblings, 2 replies; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-24 19:18 UTC (permalink / raw)
  To: John Fastabend, Stanislav Fomichev, Toke Høiland-Jørgensen
  Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
	Daniel Borkmann, Kernel Team

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!

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  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
  1 sibling, 1 reply; 11+ messages in thread
From: Stanislav Fomichev @ 2021-05-24 20:35 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: John Fastabend, Toke Høiland-Jørgensen,
	Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
	Daniel Borkmann, Kernel Team

On Mon, May 24, 2021 at 12:19 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> 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!

I took a quick look earlier today and everything looks good, thanks!
I'll try to enable strict mode in our codebase in the coming weeks to
see how it goes.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 19:18   ` Andrii Nakryiko
  2021-05-24 20:35     ` Stanislav Fomichev
@ 2021-05-24 20:53     ` Toke Høiland-Jørgensen
  2021-05-24 21:26       ` Andrii Nakryiko
  1 sibling, 1 reply; 11+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-05-24 20:53 UTC (permalink / raw)
  To: Andrii Nakryiko, John Fastabend, Stanislav Fomichev
  Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
	Daniel Borkmann, Kernel Team

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 20:35     ` Stanislav Fomichev
@ 2021-05-24 21:25       ` Andrii Nakryiko
  0 siblings, 0 replies; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-24 21:25 UTC (permalink / raw)
  To: Stanislav Fomichev
  Cc: John Fastabend, Toke Høiland-Jørgensen,
	Andrii Nakryiko, bpf, Networking, Alexei Starovoitov,
	Daniel Borkmann, Kernel Team

On Mon, May 24, 2021 at 1:35 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> On Mon, May 24, 2021 at 12:19 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > 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!
>
> I took a quick look earlier today and everything looks good, thanks!

Great, thanks for looking.

> I'll try to enable strict mode in our codebase in the coming weeks to
> see how it goes.

Keep in mind, if you do libbpf_set_strict_mode(LIBBPF_STRICT_ALL) you
are automatically opting in for all the future "features", so for
production you might want to go conservative and start with specifying
explicitly LIBBPF_STRICT_DIRECT_ERRS | LIBBPF_STRICT_CLEAN_PTRS, and
then add more as you check that your code will handle new changes.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 20:53     ` Toke Høiland-Jørgensen
@ 2021-05-24 21:26       ` Andrii Nakryiko
  2021-05-24 21:34         ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-24 21:26 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: John Fastabend, Stanislav Fomichev, Andrii Nakryiko, bpf,
	Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 21:26       ` Andrii Nakryiko
@ 2021-05-24 21:34         ` Toke Høiland-Jørgensen
  2021-05-24 21:46           ` Andrii Nakryiko
  0 siblings, 1 reply; 11+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-05-24 21:34 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: John Fastabend, Stanislav Fomichev, Andrii Nakryiko, bpf,
	Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

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

Right, OK, I'll stop looking for bugs on my end, then :)

BTW, one more thing that just came to mind: since that gdoc is not
likely to be around forever, would it be useful to make the reference in
the commit message(s) point to something more stable? IDK what that
shoul be, really. Maybe just pasting (an abbreviated outline of?) the
text in the document into the cover letter / merge commit could work?

-Toke


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  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
  0 siblings, 1 reply; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-24 21:46 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: John Fastabend, Stanislav Fomichev, Andrii Nakryiko, bpf,
	Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team

On Mon, May 24, 2021 at 2:34 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>
> > 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.
>
> Right, OK, I'll stop looking for bugs on my end, then :)
>
> BTW, one more thing that just came to mind: since that gdoc is not
> likely to be around forever, would it be useful to make the reference in
> the commit message(s) point to something more stable? IDK what that
> shoul be, really. Maybe just pasting (an abbreviated outline of?) the
> text in the document into the cover letter / merge commit could work?

I was hoping Google won't deprecate Google Docs any time soon and I
had no intention to remove that document. But I was also thinking to
start wiki page at github.com/libbpf/libbpf with migration
instructions, so once that is up and running I can link that from
libbpf_set_strict_mode() doc comment. But I'd like to avoid blocking
on that.

>
> -Toke
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 21:46           ` Andrii Nakryiko
@ 2021-05-24 22:19             ` Toke Høiland-Jørgensen
  2021-05-25  0:06               ` Andrii Nakryiko
  0 siblings, 1 reply; 11+ messages in thread
From: Toke Høiland-Jørgensen @ 2021-05-24 22:19 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: John Fastabend, Stanislav Fomichev, Andrii Nakryiko, bpf,
	Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team

Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:

> On Mon, May 24, 2021 at 2:34 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>>
>> > 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.
>>
>> Right, OK, I'll stop looking for bugs on my end, then :)
>>
>> BTW, one more thing that just came to mind: since that gdoc is not
>> likely to be around forever, would it be useful to make the reference in
>> the commit message(s) point to something more stable? IDK what that
>> shoul be, really. Maybe just pasting (an abbreviated outline of?) the
>> text in the document into the cover letter / merge commit could work?
>
> I was hoping Google won't deprecate Google Docs any time soon and I
> had no intention to remove that document. But I was also thinking to
> start wiki page at github.com/libbpf/libbpf with migration
> instructions, so once that is up and running I can link that from
> libbpf_set_strict_mode() doc comment.

Right, that sounds reasonable :)

> But I'd like to avoid blocking on that.

Understandable; but just pasting an outline into the commit message (and
keeping the link) could work in the meantime?

-Toke


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next 0/5] libbpf: error reporting changes for v1.0
  2021-05-24 22:19             ` Toke Høiland-Jørgensen
@ 2021-05-25  0:06               ` Andrii Nakryiko
  0 siblings, 0 replies; 11+ messages in thread
From: Andrii Nakryiko @ 2021-05-25  0:06 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: John Fastabend, Stanislav Fomichev, Andrii Nakryiko, bpf,
	Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team

On Mon, May 24, 2021 at 3:20 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>
> > On Mon, May 24, 2021 at 2:34 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >>
> >> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> >>
> >> > 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.
> >>
> >> Right, OK, I'll stop looking for bugs on my end, then :)
> >>
> >> BTW, one more thing that just came to mind: since that gdoc is not
> >> likely to be around forever, would it be useful to make the reference in
> >> the commit message(s) point to something more stable? IDK what that
> >> shoul be, really. Maybe just pasting (an abbreviated outline of?) the
> >> text in the document into the cover letter / merge commit could work?
> >
> > I was hoping Google won't deprecate Google Docs any time soon and I
> > had no intention to remove that document. But I was also thinking to
> > start wiki page at github.com/libbpf/libbpf with migration
> > instructions, so once that is up and running I can link that from
> > libbpf_set_strict_mode() doc comment.
>
> Right, that sounds reasonable :)
>
> > But I'd like to avoid blocking on that.
>
> Understandable; but just pasting an outline into the commit message (and
> keeping the link) could work in the meantime?

I'm not sure what are we trying to achieve by copy/pasting parts of
that doc here. Each patch succinctly explains how each feature
behaves, so it's completely self-describing. I put the link to the
document for anyone that wants to read the entire discussion or leave
some more comments, but it's not mandatory to understand this patch
set.

>
> -Toke
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-05-25  0:07 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.