Commit 62fc770d authored by Paul E. McKenney's avatar Paul E. McKenney Committed by Alexei Starovoitov

bpf: Update bpf_design_QA.rst to clarify that attaching to functions is not ABI

This patch updates bpf_design_QA.rst to clarify that the ability to
attach a BPF program to an arbitrary function in the kernel does not
make that function become part of the Linux kernel's ABI.

[ paulmck: Apply Daniel Borkmann feedback. ]
Signed-off-by: default avatarPaul E. McKenney <paulmck@kernel.org>
Link: https://lore.kernel.org/r/20220802173913.4170192-2-paulmck@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
parent b9b738ee
...@@ -279,3 +279,15 @@ cc (congestion-control) implementations. If any of these kernel ...@@ -279,3 +279,15 @@ cc (congestion-control) implementations. If any of these kernel
functions has changed, both the in-tree and out-of-tree kernel tcp cc functions has changed, both the in-tree and out-of-tree kernel tcp cc
implementations have to be changed. The same goes for the bpf implementations have to be changed. The same goes for the bpf
programs and they have to be adjusted accordingly. programs and they have to be adjusted accordingly.
Q: Attaching to arbitrary kernel functions is an ABI?
-----------------------------------------------------
Q: BPF programs can be attached to many kernel functions. Do these
kernel functions become part of the ABI?
A: NO.
The kernel function prototypes will change, and BPF programs attaching to
them will need to change. The BPF compile-once-run-everywhere (CO-RE)
should be used in order to make it easier to adapt your BPF programs to
different versions of the kernel.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment