Changes in Makefile

4989135a - bpf: Remove redundant slash

Sat, 05 Mar 2022 16:10:13 +0000

bpf: Remove redundant slashThe trailing slash of LIBBPF_SRCS is redundant, remove it. Also inlineit as its only used in LIBBPF_INCLUDE.Signed-off-by: Yuntao Wang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220305161013.361646-1-ytcoode@gmail.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

cb80ddc6 - bpf: Convert bpf_preload.ko to use light skeleton.

Wed, 09 Feb 2022 23:20:01 +0000

bpf: Convert bpf_preload.ko to use light skeleton.The main change is a move of the single line #include "iterators.lskel.h"from iterators/iterators.c to bpf_preload_kern.c.Which means that generated light skeleton can be used from user space oruser mode driver like iterators.c or from the kernel module or the kernel itself.The direct use of light skeleton from the kernel module simplifies the code,since UMD is no longer necessary. The libbpf.a required user space and UMD. TheCO-RE in the kernel and generated "loader bpf program" used by the lightskeleton are capable to perform complex loading operations traditionallyprovided by libbpf. In addition UMD approach was launching UMD processevery time bpffs has to be mounted. With light skeleton in the kernelthe bpf_preload kernel module loads bpf iterators once and pins themmultiple times into different bpffs mounts.Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220209232001.27490-6-alexei.starovoitov@gmail.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

e96f2d64 - bpf: Drop libbpf, libelf, libz dependency from bpf preload.

Mon, 31 Jan 2022 22:05:28 +0000

bpf: Drop libbpf, libelf, libz dependency from bpf preload.Drop libbpf, libelf, libz dependency from bpf preload.This reduces bpf_preload_umd binary sizefrom 1.7M to 30k unstripped with debug infoand from 300k to 19k stripped.Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20220131220528.98088-8-alexei.starovoitov@gmail.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

5f52d47c - bpf/preload: Clean up .gitignore and "clean-files" target

Wed, 20 Oct 2021 09:46:47 +0000

bpf/preload: Clean up .gitignore and "clean-files" targetkernel/bpf/preload/Makefile was recently updated to have it installlibbpf's headers locally instead of pulling them from tools/lib/bpf. Buttwo items still need to be addressed.First, the local .gitignore file was not adjusted to ignore the filesgenerated in the new kernel/bpf/preload/libbpf output directory.Second, the "clean-files" target is now incorrect. The old artefactsnames were not removed from the target, while the new ones were addedincorrectly. This is because "clean-files" expects names relative to$(obj), but we passed the absolute path instead. This results in theoutput and header-destination directories for libbpf (and theircontents) not being removed from kernel/bpf/preload on "make clean" fromthe root of the repository.This commit fixes both issues. Note that $(userprogs) needs not be addedto "clean-files", because the cleaning infrastructure already accountsfor it.Cleaning the files properly also prevents make from printing thefollowing message, for builds coming after a "make clean":"make[4]: Nothing to be done for 'install_headers'."v2: Simplify the "clean-files" target.Fixes: bf60791741d4 ("bpf: preload: Install libbpf headers when building")Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20211020094647.15564-1-quentin@isovalent.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

bf607917 - bpf: preload: Install libbpf headers when building

Thu, 07 Oct 2021 19:44:32 +0000

bpf: preload: Install libbpf headers when buildingAPI headers from libbpf should not be accessed directly from thelibrary's source directory. Instead, they should be exported with "makeinstall_headers". Let's make sure that bpf/preload/Makefile installs theheaders properly when building.Note that we declare an additional dependency for iterators/iterators.o:having $(LIBBPF_A) as a dependency to "$(obj)/bpf_preload_umd" is notsufficient, as it makes it required only at the linking step. But weneed libbpf to be compiled, and in particular its headers to beexported, before we attempt to compile iterators.o. The issue would notoccur before this commit, because libbpf's headers were not exported andwere always available under tools/lib/bpf.Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211007194438.34443-7-quentin@isovalent.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

2f383041 - libbpf: Make libbpf_version.h non-auto-generated

Mon, 13 Sep 2021 22:23:09 +0000

libbpf: Make libbpf_version.h non-auto-generatedTurn previously auto-generated libbpf_version.h header into a normalheader file. This prevents various tricky Makefile integration issues,simplifies the overall build process, but also allows to further extendit with some more versioning-related APIs in the future.To prevent accidental out-of-sync versions as defined by libbpf.map andlibbpf_version.h, Makefile checks their consistency at build time.Simultaneously with this change bump libbpf.map to v0.6.Also undo adding libbpf's output directory into include path forkernel/bpf/preload, bpftool, and resolve_btfids, which is not necessarybecause libbpf_version.h is just a normal header like any other.Fixes: 0b46b7550560 ("libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations")Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210913222309.3220849-1-andrii@kernel.org List of files: /linux-6.15/kernel/bpf/preload/Makefile

0b46b755 - libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations

Wed, 08 Sep 2021 21:32:26 +0000

libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecationsIntroduce a macro LIBBPF_DEPRECATED_SINCE(major, minor, message) to preparethe deprecation of two API functions. This macro marks functions as deprecatedwhen libbpf's version reaches the values passed as an argument.As part of this change libbpf_version.h header is added with recorded major(LIBBPF_MAJOR_VERSION) and minor (LIBBPF_MINOR_VERSION) libbpf version macros.They are now part of libbpf public API and can be relied upon by user code.libbpf_version.h is installed system-wide along other libbpf public headers.Due to this new build-time auto-generated header, in-kernel applicationsrelying on libbpf (resolve_btfids, bpftool, bpf_preload) are updated toinclude libbpf's output directory as part of a list of include search paths.Better fix would be to use libbpf's make_install target to install public APIheaders, but that clean up is left out as a future improvement. The buildchanges were tested by building kernel (with KBUILD_OUTPUT and O= specifiedexplicitly), bpftool, libbpf, selftests/bpf, and resolve_btfids builds. Noproblems were detected.Note that because of the constraints of the C preprocessor we have to writea few lines of macro magic for each version used to prepare deprecation (0.6for now).Also, use LIBBPF_DEPRECATED_SINCE() to schedule deprecation ofbtf__get_from_id() and btf__load(), which are replaced bybtf__load_from_kernel_by_id() and btf__load_into_kernel(), respectively,starting from future libbpf v0.6. This is part of libbpf 1.0 effort ([0]). [0] Closes: https://github.com/libbpf/libbpf/issues/278Co-developed-by: Quentin Monnet Co-developed-by: Andrii Nakryiko Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210908213226.1871016-1-andrii@kernel.org List of files: /linux-6.15/kernel/bpf/preload/Makefile

150a2732 - bpf, preload: Fix build when $(O) points to a relative path

Tue, 26 Jan 2021 16:13:20 +0000

bpf, preload: Fix build when $(O) points to a relative pathBuilding the kernel with CONFIG_BPF_PRELOAD, and by providing a relativepath for the output directory, may fail with the following error: $ make O=build bindeb-pkg ... /.../linux/tools/scripts/Makefile.include:5: *** O=build does not exist. Stop. make[7]: *** [/.../linux/kernel/bpf/preload/Makefile:9: kernel/bpf/preload/libbpf.a] Error 2 make[6]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf/preload] Error 2 make[5]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf] Error 2 make[4]: *** [/.../linux/Makefile:1799: kernel] Error 2 make[4]: *** Waiting for unfinished jobs....In the case above, for the "bindeb-pkg" target, the error is produced bythe "dummy" check in Makefile.include, called from libbpf's Makefile.This check changes directory to $(PWD) before checking for the existenceof $(O). But at this step we have $(PWD) pointing to "/.../linux/build",and $(O) pointing to "build". So the Makefile.include tries in fact toassert the existence of a directory named "/.../linux/build/build",which does not exist.Note that the error does not occur for all make targets andarchitectures combinations. This was observed on x86 for "bindeb-pkg",or for a regular build for UML [0].Here are some details. The root Makefile recursively calls itself once,after changing directory to $(O). The content for the variable $(PWD) ispreserved across recursive calls to make, so it is unchanged at thisstep. For "bindeb-pkg", $(PWD) is eventually updated because the targetwrites a new Makefile (as debian/rules) and calls it indirectly throughdpkg-buildpackage. This script does not preserve $(PWD), which is resetto the current working directory when the target in debian/rules iscalled.Although not investigated, it seems likely that something similar causesUML to change its value for $(PWD).Non-trivial fixes could be to remove the use of $(PWD) from the "dummy"check, or to make sure that $(PWD) and $(O) are preserved or updated toalways play well and form a valid $(PWD)/$(O) path across the differenttargets and architectures. Instead, we take a simpler approach and justupdate $(O) when calling libbpf's Makefile, so it points to an absolutepath which should always resolve for the "dummy" check run (throughincludes) by that Makefile.David Gow previously posted a slightly different version of this patchas a RFC [0], two months ago or so. [0] https://lore.kernel.org/bpf/20201119085022.3606135-1-davidgow@google.com/t/#uFixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")Reported-by: David Gow Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Cc: Brendan Higgins Cc: Masahiro Yamada Link: https://lore.kernel.org/bpf/20210126161320.24561-1-quentin@isovalent.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

9d9aae53 - bpf/preload: Make sure Makefile cleans up after itself, and add .gitignore

Sun, 27 Sep 2020 19:30:05 +0000

bpf/preload: Make sure Makefile cleans up after itself, and add .gitignoreThe Makefile in bpf/preload builds a local copy of libbpf, but does notproperly clean up after itself. This can lead to subsequent compilationfailures, since the feature detection cache is kept around which can leadsubsequent detection to fail.Fix this by properly setting clean-files, and while we're at it, also add a.gitignore for the directory to ignore the build artifacts.Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200927193005.8459-1-toke@redhat.com List of files: /linux-6.15/kernel/bpf/preload/Makefile

d71fa5c9 - bpf: Add kernel module with user mode driver that populates bpffs.

Wed, 19 Aug 2020 04:27:58 +0000

bpf: Add kernel module with user mode driver that populates bpffs.Add kernel module with user mode driver that populates bpffs withBPF iterators.$ mount bpffs /my/bpffs/ -t bpf$ ls -la /my/bpffs/total 4drwxrwxrwt 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.debugThe user mode driver will load BPF Type Formats, create BPF maps, populate BPFmaps, load two BPF programs, attach them to BPF iterators, and finally send twobpf_link IDs back to the kernel.The kernel will pin two bpf_links into newly mounted bpffs instance undernames "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_accessThe BPF program dump_bpf_prog() in iterators.bpf.c is printing this data aboutall BPF programs currently loaded in the system. This information is unstableand will change from kernel to kernel as ".debug" suffix conveys.Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20200819042759.51280-4-alexei.starovoitov@gmail.com List of files: /linux-6.15/kernel/bpf/preload/Makefile