[PATCH bpf-next v3 0/1] Document kfunc lifecycle / stability expectations

David Vernet
2023-02-03T15:57:38Z

This is v3 of the proposal for documenting BPF kfunc lifecycle and
stability.

v1: https://lore.kernel.org/all/20230202163056.658641-1-void@manifault.com/
v2: https://lore.kernel.org/bpf/20230202223557.744110-1-void@manifault.com/T/

Much of this proposal is based on Toke's writing, and group discussions
at BPF office hours.

Changelog
---------
v2 -> v3:
- Add Co-developed-by tag for Toke, and Reviewed-by tag for Bagas.
- s/period period/period (Donald).
- s/other kfuncs may/usually kfuncs will (Donald).
- Remove verbiage encouraging users to upstream BPF programs (Donald and
Toke).
- Collapse two paragraphs in KF_DEPRECATED section, and apply Toke's
suggested wording (Toke).
- s/highly encouraged/encouraged (Toke).
- Use phrasing that is less bad than "more similarly" (Toke).
- s/Said in a different way/In other words (Toke).
- Reword section about out-of-tree BPF program kfunc users being
relevant to discussions, per Toke's suggested wording (Toke).
- Drop unnecessary extra verbiage in paragraph explicitly stating
that kfuncs have no hard stability guarantees (Toke).
- Reword second paragraph of 3.1 kfunc deprecation to have cleaner
language (Toke).
- Drop extraneous qualifier regarding a deprecated kfunc being dropped
early (Toke).

v1 -> v2:
- Move some of the main points of the arguments around. v1 underscored
quite strongly that kfuncs don't have _any_ stability guarantees.
While true, it may scare away users who misinterpret the implications
of that to mean that things will change wildly and at any time.
Reframe the general flow of the section to be clear that no stability
is guaranteed, but front-load the content that clarifies why this
isn't necessarily something to be afraid of for users (Toke, Daniel,
and others).
- Add a paragraph explaining that out-of-tree BPF programs that use
kfuncs are relevant to discussions surrounding whether kfuncs should
be modified or removed. While the onus is on kfunc users to explicitly
engage with the upstream community to let them know which kfuncs
they're using and why they're useful, the added paragraph also makes
it clear that the BPF community will in turn participate in upstream
discussions to ensure that such users aren't equated with out-of-tree
module users, and outright ignored. Also make it clear that our hope
is that BPF programs will be upstreamed on a more regular basis (Toke,
Daniel, and others).
- Remove patches that add KF_DEPRECATED flag to <linux/btf.h>. They'll
remain in the documentation for now, and will be merged at a later
time when it's actually a useful signal for developers (Alexei and
Daniel).

David Vernet (1):
bpf/docs: Document kfunc lifecycle / stability expectations

Documentation/bpf/kfuncs.rst | 126 +++++++++++++++++++++++++++++++++--
1 file changed, 121 insertions(+), 5 deletions(-)

--
2.39.0