From: David Vernet <void@manifault.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, song@kernel.org, yhs@meta.com,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
toke@redhat.com, brouer@redhat.com, corbet@lwn.net,
linux-doc@vger.kernel.org
Subject: [PATCH bpf-next 0/3] Document kfunc lifecycle / stability expectations
Date: Thu, 2 Feb 2023 10:30:53 -0600 [thread overview]
Message-ID: <20230202163056.658641-1-void@manifault.com> (raw)
BPF kernel <-> kernel API stability has been discussed at length over
the last several weeks and months. Now that we've largely aligned over
kfuncs being the way forward, and BPF helpers being considered frozen,
it's time to document the expectations for kfunc lifecycles and
stability so that everyone (BPF users, kfunc developers, and
maintainers) are all aligned, and have a crystal-clear understanding of
the expectations surrounding kfuncs.
This patch set adds that documentation to the main kfuncs documentation
page via a new 'kfunc lifecycle expectations' section. The documentation
describes how decisions are made in the kernel regarding whether to
include, keep, deprecate, or change / remove a kfunc. As described very
overtly in the patch set itself, but likely worth highlighting here:
"kfunc stability" does not mean, nor ever will mean, "BPF APIs may block
development elsewhere in the kernel".
Rather, the intention and expectation is for kfuncs to be treated like
EXPORT_SYMBOL_GPL symbols in the kernel. The goal is for kfuncs to be a
safe and valuable option for maintainers and kfunc developers to extend
the kernel, without tying anyone's hands, or imposing any kind of
restrictions on maintainers in the same way that UAPI changes do.
Note that other proposals for this documentation have been made as well.
Toke has proposed several iterations to this doc, with the latest being
[0].
[0]: https://lore.kernel.org/all/20230201174449.94650-1-toke@redhat.com/
David Vernet (3):
bpf/docs: Document kfunc lifecycle / stability expectations
bpf: Add KF_DEPRECATED kfunc flag
selftests/bpf: Add a selftest for the KF_DEPRECATED kfunc flag
Documentation/bpf/kfuncs.rst | 125 +++++++++++++++++-
include/linux/btf.h | 1 +
kernel/bpf/verifier.c | 8 ++
net/bpf/test_run.c | 5 +
.../selftests/bpf/prog_tests/kfunc_call.c | 2 +
.../selftests/bpf/progs/kfunc_call_test.c | 10 ++
6 files changed, 146 insertions(+), 5 deletions(-)
--
2.39.0
next reply other threads:[~2023-02-02 16:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 16:30 David Vernet [this message]
2023-02-02 16:30 ` [PATCH bpf-next 1/3] bpf/docs: Document kfunc lifecycle / stability expectations David Vernet
2023-02-02 16:30 ` [PATCH bpf-next 2/3] bpf: Add KF_DEPRECATED kfunc flag David Vernet
2023-02-02 21:21 ` Alexei Starovoitov
2023-02-02 21:27 ` David Vernet
2023-02-02 23:11 ` Daniel Borkmann
2023-02-02 23:21 ` Alexei Starovoitov
2023-02-03 0:02 ` Toke Høiland-Jørgensen
2023-02-02 16:30 ` [PATCH bpf-next 3/3] selftests/bpf: Add a selftest for the " David Vernet
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=20230202163056.658641-1-void@manifault.com \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=toke@redhat.com \
--cc=yhs@meta.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;
as well as URLs for NNTP newsgroup(s).