mirror of https://gitee.com/openharmony/third_party_libbpf synced 2024-10-07 22:43:33 +00:00

Go to file

Andrii Nakryiko 2b0cd55bf5 libbpf: Teach bpf_object__open to guess program types Teach bpf_object__open how to guess program type and expected attach type from section names, similar to what bpf_prog_load() does. This seems like a really useful features and an oversight to not have this done during bpf_object_open(). To preserver backwards compatible behavior of bpf_prog_load(), its attr->prog_type is treated as an override of bpf_object__open() decisions, if attr->prog_type is not UNSPECIFIED. There is a slight difference in behavior for bpf_prog_load(). Previously, if bpf_prog_load() was loading BPF object with more than one program, first program's guessed program type and expected attach type would determine corresponding attributes of all the subsequent program types, even if their sections names suggest otherwise. That seems like a rather dubious behavior and with this change it will behave more sanely: each program's type is determined individually, unless they are forced to uniformity through attr->prog_type. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191021033902.3856966-5-andriin@fb.com		2019-10-22 16:15:55 -07:00
include	tools: Sync if_link.h	2019-10-22 16:15:55 -07:00
scripts	sync: adjust sync script for test_libbpf.c rename and bpf_helper_defs.h	2019-10-15 19:43:48 -07:00
src	libbpf: Teach bpf_object__open to guess program types	2019-10-22 16:15:55 -07:00
travis-ci/managers	ci: disable GCC's -Wstringop-truncation noisy error	2019-10-15 19:43:48 -07:00
.travis.yml	Travis CI: add gcc-8, gcc-8 ASan+UBSan tests	2019-04-30 11:39:37 -07:00
BPF-CHECKPOINT-COMMIT	sync: latest libbpf changes from kernel	2019-10-15 19:43:48 -07:00
CHECKPOINT-COMMIT	sync: latest libbpf changes from kernel	2019-10-15 19:43:48 -07:00
README.md	meson: kill meson.build as it's not used anymore	2019-10-01 16:51:32 -07:00

README.md

This is a mirror of bpf-next linux tree's tools/lib/bpf directory plus its supporting header files.

The following files will by sync'ed with bpf-next repo:

src/ <-> bpf-next/tools/lib/bpf/
include/uapi/linux/bpf_common.h <-> bpf-next/tools/include/uapi/linux/bpf_common.h
include/uapi/linux/bpf.h <-> bpf-next/tools/include/uapi/linux/bpf.h
include/uapi/linux/btf.h <-> bpf-next/tools/include/uapi/linux/btf.h
include/uapi/linux/if_link.h <-> bpf-next/tools/include/uapi/linux/if_link.h
include/uapi/linux/if_xdp.h <-> bpf-next/tools/include/uapi/linux/if_xdp.h
include/uapi/linux/netlink.h <-> bpf-next/tools/include/uapi/linux/netlink.h
include/tools/libc_compat.h <-> bpf-next/tools/include/tools/libc_compat.h

Other header files at this repo (include/linux/*.h) are reduced versions of their counterpart files at bpf-next's tools/include/linux/*.h to make compilation successful.

Build

libelf is an internal dependency of libbpf and thus it is required to link against and must be installed on the system for applications to work. pkg-config is used by default to find libelf, and the program called can be overridden with PKG_CONFIG. If using pkg-config at build time is not desired, it can be disabled by setting NO_PKG_CONFIG=1 when calling make.

To build both static libbpf.a and shared libbpf.so:

$ cd src
$ make

To build only static libbpf.a library in directory build/ and install them together with libbpf headers in a staging directory root/:

$ cd src
$ mkdir build root
$ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install

To build both static libbpf.a and shared libbpf.so against a custom libelf dependency installed in /build/root/ and install them together with libbpf headers in a build directory /build/root/:

$ cd src
$ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make install