summaryrefslogtreecommitdiff
path: root/Documentation/bpf/bpf_design_QA.rst
diff options
context:
space:
mode:
authorKumar Kartikeya Dwivedi <memxor@gmail.com>2022-11-14 22:15:22 +0300
committerAlexei Starovoitov <ast@kernel.org>2022-11-15 08:52:45 +0300
commit1f6d52f1a8947436dc5b2575e2fffb831f240141 (patch)
treefc904166e145fd51837cc51c9e8250ef9b8c2d79 /Documentation/bpf/bpf_design_QA.rst
parentde763fbb2c5bfad1ab7c4232e6a804726f0b0744 (diff)
downloadlinux-1f6d52f1a8947436dc5b2575e2fffb831f240141.tar.xz
bpf: Remove local kptr references in documentation
We don't want to commit to a specific name for these. Simply call them allocated objects coming from bpf_obj_new, which is completely clear in itself. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20221114191547.1694267-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'Documentation/bpf/bpf_design_QA.rst')
-rw-r--r--Documentation/bpf/bpf_design_QA.rst11
1 files changed, 6 insertions, 5 deletions
diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
index 17e774d96c5e..cec2371173d7 100644
--- a/Documentation/bpf/bpf_design_QA.rst
+++ b/Documentation/bpf/bpf_design_QA.rst
@@ -332,13 +332,14 @@ avoid defining types with 'bpf\_' prefix to not be broken in future releases.
In other words, no backwards compatibility is guaranteed if one using a type
in BTF with 'bpf\_' prefix.
-Q: What is the compatibility story for special BPF types in local kptrs?
-------------------------------------------------------------------------
-Q: Same as above, but for local kptrs (i.e. pointers to objects allocated using
-bpf_obj_new for user defined structures). Will the kernel preserve backwards
+Q: What is the compatibility story for special BPF types in allocated objects?
+------------------------------------------------------------------------------
+Q: Same as above, but for allocated objects (i.e. objects allocated using
+bpf_obj_new for user defined types). Will the kernel preserve backwards
compatibility for these features?
A: NO.
Unlike map value types, there are no stability guarantees for this case. The
-whole local kptr API itself is unstable (since it is exposed through kfuncs).
+whole API to work with allocated objects and any support for special fields
+inside them is unstable (since it is exposed through kfuncs).