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