Merge branch 'libbpf: remove deprecated APIs'
authorAlexei Starovoitov <ast@kernel.org>
Tue, 28 Jun 2022 20:13:33 +0000 (13:13 -0700)
committerAlexei Starovoitov <ast@kernel.org>
Tue, 28 Jun 2022 20:13:34 +0000 (13:13 -0700)
commitc5c7358e4c76e2017a6566a29208996fcca75200
tree0d943027a0358446acdfb7c0bb278a9ee9ce316c
parent697fb80a53642be624f5121b6ca9d66769c180e0
parentab9a5a05dc480f8994eddd31093a8920b08ee71d
Merge branch 'libbpf: remove deprecated APIs'

Andrii Nakryiko says:

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

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.

  [0] https://github.com/xdp-project/xdp-tools/tree/master/lib/libxdp

v1->v2:
  - rebase on latest bpf-next now that Jiri's perf patches landed;
  - fix xsk.o dependency in Makefile to ensure libbpf headers are installed
    reliably.
====================

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