From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net
Cc: andrii@kernel.org, kernel-team@fb.com
Subject: Re: [PATCH bpf-next 00/15] libbpf: remove deprecated APIs
Date: Sat, 04 Jun 2022 12:01:42 +0200 [thread overview]
Message-ID: <87wndwvjax.fsf@toke.dk> (raw)
In-Reply-To: <20220603190155.3924899-1-andrii@kernel.org>
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 :)
-Toke
next prev parent reply other threads:[~2022-06-04 10:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 19:01 [PATCH bpf-next 00/15] libbpf: remove deprecated APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 01/15] libbpf: move xsk.{c,h} into selftests/bpf Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 02/15] libbpf: remove deprecated low-level APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 03/15] libbpf: remove deprecated XDP APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 04/15] libbpf: remove deprecated probing APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 05/15] libbpf: remove deprecated BTF APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 06/15] libbpf: clean up perfbuf APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 07/15] libbpf: remove prog_info_linear APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 08/15] libbpf: remove most other deprecated high-level APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 09/15] libbpf: remove multi-instance and custom private data APIs Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 10/15] libbpf: cleanup LIBBPF_DEPRECATED_SINCE supporting macros for v0.x Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 11/15] libbpf: remove internal multi-instance prog support Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 12/15] libbpf: clean up SEC() handling Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 13/15] selftests/bpf: remove last tests with legacy BPF map definitions Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 14/15] libbpf: enforce strict libbpf 1.0 behaviors Andrii Nakryiko
2022-06-03 19:01 ` [PATCH bpf-next 15/15] libbpf: fix up few libbpf.map problems Andrii Nakryiko
2022-06-04 10:01 ` Toke Høiland-Jørgensen [this message]
2022-06-04 16:01 ` [PATCH bpf-next 00/15] libbpf: remove deprecated APIs Dave Thaler
2022-06-06 0:27 ` Andrii Nakryiko
2022-06-24 15:12 ` Toke Høiland-Jørgensen
2022-06-24 20:57 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wndwvjax.fsf@toke.dk \
--to=toke@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox