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>
This commit is contained in:
Родитель
de763fbb2c
Коммит
1f6d52f1a8
|
@ -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).
|
||||
|
|
Загрузка…
Ссылка в новой задаче