Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation/bpf: Add a description of "stable kfuncs" #4345

Closed
wants to merge 1 commit into from

Conversation

kernel-patches-bot
Copy link

Pull request for series with
subject: Documentation/bpf: Add a description of "stable kfuncs"
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=712540

Following up on the discussion at the BPF office hours, this patch adds a
description of the (new) concept of "stable kfuncs", which are kfuncs that
offer a "more stable" interface than what we have now, but is still not
part of UAPI.

This is mostly meant as a straw man proposal to focus discussions around
stability guarantees. From the discussion, it seemed clear that there were
at least some people (myself included) who felt that there needs to be some
way to export functionality that we consider "stable" (in the sense of
"applications can rely on its continuing existence").

One option is to keep BPF helpers as the stable interface and implement
some technical solution for moving functionality from kfuncs to helpers
once it has stood the test of time and we're comfortable committing to it
as a stable API. Another is to freeze the helper definitions, and instead
use kfuncs for this purpose as well, by marking a subset of them as
"stable" in some way. Or we can do both and have multiple levels of "stable",
I suppose.

This patch is an attempt to describe what the "stable kfuncs" idea might look
like, as well as to formulate some criteria for what we mean by "stable", and
describe an explicit deprecation procedure. Feel free to critique any part
of this (including rejecting the notion entirely).

Some people mentioned (in the office hours) that should we decide to go in
this direction, there's some work that needs to be done in libbpf (and
probably the kernel too?) to bring the kfunc developer experience up to par
with helpers. Things like exporting kfunc definitions to vmlinux.h (to make
them discoverable), and having CO-RE support for using them, etc. I kinda
consider that orthogonal to what's described here, but I added a
placeholder reference indicating that this (TBD) functionality exists.

Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
@kernel-patches-bot
Copy link
Author

Upstream branch: dfff86f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=712540
version: 1

@kernel-patches-bot
Copy link
Author

At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=712540 expired. Closing PR.

@kernel-patches-bot kernel-patches-bot deleted the series/712540=>bpf-next branch January 19, 2023 08:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants