On 8/3/20 12:29 AM, Alexei Starovoitov wrote:
From: Alexei Starovoitov <ast@xxxxxxxxxx> Add kernel module with user mode driver that populates bpffs with BPF iterators. $ mount bpffs /my/bpffs/ -t bpf $ ls -la /my/bpffs/ total 4 drwxrwxrwt 2 root root 0 Jul 2 00:27 . drwxr-xr-x 19 root root 4096 Jul 2 00:09 .. -rw------- 1 root root 0 Jul 2 00:27 maps.debug -rw------- 1 root root 0 Jul 2 00:27 progs.debug The user mode driver will load BPF Type Formats, create BPF maps, populate BPF maps, load two BPF programs, attach them to BPF iterators, and finally send two bpf_link IDs back to the kernel. The kernel will pin two bpf_links into newly mounted bpffs instance under names "progs.debug" and "maps.debug". These two files become human readable. $ cat /my/bpffs/progs.debug id name attached 11 dump_bpf_map bpf_iter_bpf_map 12 dump_bpf_prog bpf_iter_bpf_prog 27 test_pkt_access 32 test_main test_pkt_access test_pkt_access 33 test_subprog1 test_pkt_access_subprog1 test_pkt_access 34 test_subprog2 test_pkt_access_subprog2 test_pkt_access 35 test_subprog3 test_pkt_access_subprog3 test_pkt_access 36 new_get_skb_len get_skb_len test_pkt_access 37 new_get_skb_ifindex get_skb_ifindex test_pkt_access 38 new_get_constant get_constant test_pkt_access The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about all BPF programs currently loaded in the system. This information is unstable and will change from kernel to kernel as ".debug" suffix conveys. Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx>
[...]
diff --git a/kernel/bpf/preload/Kconfig b/kernel/bpf/preload/Kconfig new file mode 100644 index 000000000000..b8ba5a9398ed --- /dev/null +++ b/kernel/bpf/preload/Kconfig @@ -0,0 +1,18 @@ +# SPDX-License-Identifier: GPL-2.0-only +menuconfig BPF_PRELOAD + bool "Preload BPF file system with kernel specific program and map iterators" + depends on BPF + help + This builds kernel module with several embedded BPF programs that are + pinned into BPF FS mount point as human readable files that are + useful in debugging and introspection of BPF programs and maps. + +if BPF_PRELOAD +config BPF_PRELOAD_UMD + tristate "bpf_preload kernel module with user mode driver" + depends on CC_CAN_LINK + depends on m || CC_CAN_LINK_STATIC + default m + help + This builds bpf_preload kernel module with embedded user mode driver. +endif
[...] When I applied this set locally to run build & selftests I noticed that the above kconfig will appear in the top-level menuconfig. This is how it looks in menuconfig: │ ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ General setup ---> │ │ │ │ [*] 64-bit kernel │ │ │ │ Processor type and features ---> │ │ │ │ Power management and ACPI options ---> │ │ │ │ Bus options (PCI etc.) ---> │ │ │ │ Binary Emulations ---> │ │ │ │ Firmware Drivers ---> │ │ │ │ [*] Virtualization ---> │ │ │ │ General architecture-dependent options ---> │ │ │ │ [*] Enable loadable module support ---> │ │ │ │ -*- Enable the block layer ---> │ │ │ │ IO Schedulers ---> │ │ │ │ [ ] Preload BPF file system with kernel specific program and map iterators ---- │ │ │ │ Executable file formats ---> │ │ │ │ Memory Management options ---> │ │ │ │ [*] Networking support ---> │ │ │ │ Device Drivers ---> │ │ │ │ File systems ---> │ │ │ │ Security options ---> │ │ [...] I assume the original intention was to have it under 'general setup' on a similar level for the JIT settings, or is this intentional to have it at this high level next to 'networking support' and others? Thanks, Daniel
