| Message ID | 20250303135752.158343-1-mykyta.yatsenko5@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce bpf_object__prepare | expand |
Hello: This series was applied to bpf/bpf-next.git (master) by Andrii Nakryiko <andrii@kernel.org>: On Mon, 3 Mar 2025 13:57:48 +0000 you wrote: > From: Mykyta Yatsenko <yatsenko@meta.com> > > We are introducing a new function in the libbpf API, bpf_object__prepare, > which provides more granular control over the process of loading a > bpf_object. bpf_object__prepare performs ELF processing, relocations, > prepares final state of BPF program instructions (accessible with > bpf_program__insns()), creates and potentially pins maps, and stops short > of loading BPF programs. > > [...] Here is the summary with links: - [bpf-next,v2,1/4] libbpf: use map_is_created helper in map setters https://git.kernel.org/bpf/bpf-next/c/7218ff1f322d - [bpf-next,v2,2/4] libbpf: introduce more granular state for bpf_object https://git.kernel.org/bpf/bpf-next/c/8ca8f6d1a2b4 - [bpf-next,v2,3/4] libbpf: split bpf object load into prepare/load https://git.kernel.org/bpf/bpf-next/c/da755540c6f8 - [bpf-next,v2,4/4] selftests/bpf: add tests for bpf_object__prepare https://git.kernel.org/bpf/bpf-next/c/68b61a823aab You are awesome, thank you!
From: Mykyta Yatsenko <yatsenko@meta.com> We are introducing a new function in the libbpf API, bpf_object__prepare, which provides more granular control over the process of loading a bpf_object. bpf_object__prepare performs ELF processing, relocations, prepares final state of BPF program instructions (accessible with bpf_program__insns()), creates and potentially pins maps, and stops short of loading BPF programs. There are couple of anticipated usecases for this API: * Use BPF token for freplace programs that might need to lookup BTF of other programs (BPF token creation can't be moved to open step, as open step is "no privilege assumption" step so that tools like bpftool can generate skeleton, discover the structure of BPF object, etc). * Stopping at prepare gives users finalized BPF program instructions (with subprogs appended, everything relocated and finalized, etc). And that property can be taken advantage of by veristat (and similar tools) that might want to process one program at a time, but would like to avoid relatively slow ELF parsing and processing; and even BPF selftests itself (RUN_TESTS part of it at least) would benefit from this by eliminating waste of re-processing ELF many times. Mykyta Yatsenko (4): libbpf: use map_is_created helper in map setters libbpf: introduce more granular state for bpf_object libbpf: split bpf object load into prepare/load selftests/bpf: add tests for bpf_object__prepare tools/lib/bpf/libbpf.c | 197 ++++++++++++------ tools/lib/bpf/libbpf.h | 13 ++ tools/lib/bpf/libbpf.map | 1 + .../selftests/bpf/prog_tests/prepare.c | 99 +++++++++ tools/testing/selftests/bpf/progs/prepare.c | 28 +++ 5 files changed, 271 insertions(+), 67 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/prepare.c create mode 100644 tools/testing/selftests/bpf/progs/prepare.c