Re: [PATCH bpf-next 00/15] libbpf: remove deprecated APIs

["Toke Høiland-Jørgensen" <toke@kernel.org>]

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

> On Sat, Jun 4, 2022 at 3:01 AM Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>>
>> Andrii Nakryiko <andrii@kernel.org> writes:
>>
>> > This patch set removes all the deprecated APIs in preparation for 1.0 release.
>> > It also makes libbpf_set_strict_mode() a no-op (but keeps it to let per-1.0
>> > applications buildable and dynamically linkable against libbpf 1.0 if they
>> > were already libbpf-1.0 ready) and starts enforcing all the
>> > behaviors that were previously opt-in through libbpf_set_strict_mode().
>> >
>> > xsk.{c,h} parts that are now properly provided by libxdp ([0]) are still used
>> > by xdpxceiver.c in selftest/bpf, so I've moved xsk.{c,h} with barely any
>> > changes to under selftests/bpf.
>> >
>> > Other than that, apart from removing all the LIBBPF_DEPRECATED-marked APIs,
>> > there is a bunch of internal clean ups allowed by that. I've also "restored"
>> > libbpf.map inheritance chain while removing all the deprecated APIs. I think
>> > that's the right way to do this, as applications using libbpf as shared
>> > library but not relying on any deprecated APIs (i.e., "good citizens" that
>> > prepared for libbpf 1.0 release ahead of time to minimize disruption) should
>> > be able to link both against 0.x and 1.x versions. Either way, it doesn't seem
>> > to break anything and preserve a history on when each "surviving" API was
>> > added.
>> >
>> > NOTE. This shouldn't be yet landed until Jiri's changes ([1]) removing last
>> > deprecated API usage in perf lands. But I thought to post it now to get the
>> > ball rolling.
>>
>> Any chance you could push this to a branch of github as well? Makes it
>> easier to test libxdp against it :)
>>
>
> Sure, pushed to
> https://github.com/libbpf/libbpf/tree/libbpf-remove-deprecated-apis

Hi Andrii

Took this for a test run, and besides having to fix up the Makefile in
the github repository a bit (diff below), nothing broke
catastrophically. So yay!

It did flush out a BPF object file we used for testing that still had
the old long-style section name, but libbpf does output a helpful error
message for that even if it can get lost in the noise. So I guess that's
as friendly as we can make it :)

-Toke


diff --git a/src/Makefile b/src/Makefile
index 40f4f98b5681..99766f4c418c 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -8,8 +8,8 @@ else
        msg = @printf '  %-8s %s%s\n' "$(1)" "$(2)" "$(if $(3), $(3))";
 endif
 
-LIBBPF_MAJOR_VERSION := 0
-LIBBPF_MINOR_VERSION := 8
+LIBBPF_MAJOR_VERSION := 1
+LIBBPF_MINOR_VERSION := 0
 LIBBPF_PATCH_VERSION := 0
 LIBBPF_VERSION := $(LIBBPF_MAJOR_VERSION).$(LIBBPF_MINOR_VERSION).$(LIBBPF_PATCH_VERSION)
 LIBBPF_MAJMIN_VERSION := $(LIBBPF_MAJOR_VERSION).$(LIBBPF_MINOR_VERSION).0
@@ -50,7 +50,7 @@ OBJDIR ?= .
 SHARED_OBJDIR := $(OBJDIR)/sharedobjs
 STATIC_OBJDIR := $(OBJDIR)/staticobjs
 OBJS := bpf.o btf.o libbpf.o libbpf_errno.o netlink.o \
-       nlattr.o str_error.o libbpf_probes.o bpf_prog_linfo.o xsk.o \
+       nlattr.o str_error.o libbpf_probes.o bpf_prog_linfo.o  \
        btf_dump.o hashmap.o ringbuf.o strset.o linker.o gen_loader.o \
        relo_core.o usdt.o
 SHARED_OBJS := $(addprefix $(SHARED_OBJDIR)/,$(OBJS))
@@ -64,7 +64,7 @@ ifndef BUILD_STATIC_ONLY
        VERSION_SCRIPT := libbpf.map
 endif
 
-HEADERS := bpf.h libbpf.h btf.h libbpf_common.h libbpf_legacy.h xsk.h \
+HEADERS := bpf.h libbpf.h btf.h libbpf_common.h libbpf_legacy.h  \
           bpf_helpers.h bpf_helper_defs.h bpf_tracing.h \
           bpf_endian.h bpf_core_read.h skel_internal.h libbpf_version.h \
           usdt.bpf.h