On Fri, Jun 24, 2022 at 8:12 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:
>
> > On Sat, Jun 4, 2022 at 3:01 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> >>
> >> Andrii Nakryiko <andrii@xxxxxxxxxx> 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 :)
>
Cool, thanks for testing! And yeah, I should try and not forget to do
these Github-only changes when I do proper sync, thanks for the
reminder! Now that Jiri's perf patch is merged, I'll rebase my changes
and post them as v2.
> -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
