Merge branch 'Future-proof more tricky libbpf APIs'
authorAlexei Starovoitov <ast@kernel.org>
Fri, 12 Nov 2021 00:54:06 +0000 (16:54 -0800)
committerAlexei Starovoitov <ast@kernel.org>
Fri, 12 Nov 2021 00:54:06 +0000 (16:54 -0800)
commit2326ff8d5c6628e581c87f37a8f6db1db7dc00ee
treee168c3961048232aba7e298b28a526890d5b468b
parent3a75111d8a430ac6684e04172c9f84e9b1b1454e
parent164b04f27fbd769f57905dfddd2a8953974eeef4
Merge branch 'Future-proof more tricky libbpf APIs'

Andrii Nakryiko says:

====================

This patch set continues the work of revamping libbpf APIs that are not
extensible, as they were added before we figured out all the intricacies of
building APIs that can preserve ABI compatibility (both backward and forward).

What makes them tricky is that (most of) these APIs are actively used by
multiple applications, so we need to be careful about refactoring them. See
individual patches for details, but the general approach is similar to
previous bpf_prog_load() API revamp. The biggest different and complexity is
in changing btf_dump__new(), because function overloading through macro magic
doesn't work based on number of arguments, as both new and old APIs have
4 arguments. Because of that, another overloading approach is taken; overload
happens based on argument types.

I've validated manually (by using local test_progs-shared flavor that is
compiling test_progs against libbpf as a shared library) that compiling "old
application" (selftests before being adapted to using new variants of revamped
APIs) are compiled and successfully run against newest libbpf version as well
as the older libbpf version (provided no new variants are used). All these
scenarios seem to be working as expected.

v1->v2:
  - add explicit printf_fn NULL check in btf_dump__new() (Alexei);
  - replaced + with || in __builtin_choose_expr() (Alexei);
  - dropped test_progs-shared flavor (Alexei).
====================

Signed-off-by: Alexei Starovoitov <ast@kernel.org>