Run kernel selftests in vmtest with the goal to test libbpf backward compatibility with older kernels. The list of kernels should be specified in .travis.yml config in `jobs` section, e.g. KERNEL=5.5.0. Enlisted kernel releases - 5.5.0 # built from main - 5.5.0-rc6 # built from bpf-next - LATEST The kernel specified as 'LATEST' in .travis.yml is built from bpf-next kernel tree, the rest of the kernels are downloaded from the specified in INDEX file. The kernel sources from bpf-next are manually patched with [1] from bpf tree to fix ranqslower build. This workaround should be removed after the patch is merged from bpf to bpf-next tree. Due to kernel sources being checked out the duration of the LATEST kernel test is ~30m. bpf selftests are built from tools/testing/selftests/bpf/ of bpf-next tree with HEAD revision set to CHECKPOINT-COMMIT specified in libbpf so selftests and libbpf are in sync. Currently only programs are tested with test_progs program, test_maps and test_verifier should follow. test_progs are run with blacklist required due to: - some features, e.g. fentry/fexit are not supported in older kernels - environment limitations, e.g an absence of the recent pahole in Debian - incomplete disk image The blacklist is passed to test_progs with -b option as specified in [2] patch set. Most of the preceeding tests are disabled due to incomplete disk image currenly lacking proper networking settings. For the LATEST kernel fome fentry/fexit tests are disabled due to pahole v1.16 is not abailible in Debian yet. Next steps are resolving issues with blacklisted tests, enabling maps and verifier testing, expanding the list of tested kernels. [1] https://lore.kernel.org/bpf/908498f794661c44dca54da9e09dc0c382df6fcb.1580425879.git.hex@fb.com/t.mbox.gz [2] https://www.spinics.net/lists/netdev/msg625192.html
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.hinclude/uapi/linux/bpf.h<->bpf-next/tools/include/uapi/linux/bpf.hinclude/uapi/linux/btf.h<->bpf-next/tools/include/uapi/linux/btf.hinclude/uapi/linux/if_link.h<->bpf-next/tools/include/uapi/linux/if_link.hinclude/uapi/linux/if_xdp.h<->bpf-next/tools/include/uapi/linux/if_xdp.hinclude/uapi/linux/netlink.h<->bpf-next/tools/include/uapi/linux/netlink.hinclude/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
Distributions
Distributions packaging libbpf from this mirror:
Benefits of packaging from the mirror over packaging from kernel sources:
- Consistent versioning across distributions.
- No ties to any specific kernel, transparent handling of older kernels. Libbpf is designed to be kernel-agnostic and work across multitude of kernel versions. It has built-in mechanisms to gracefully handle older kernels, that are missing some of the features, by working around or gracefully degrading functionality. Thus libbpf is not tied to a specific kernel version and can/should be packaged and versioned independently.
- Continuous integration testing via TravisCI.
- Static code analysis via LGTM and Coverity.
Package dependencies of libbpf, package names may vary across distros:
- zlib
- libelf
License
This work is dual-licensed under BSD 2-clause license and GNU LGPL v2.1 license. You can choose between one of them if you use this work.
SPDX-License-Identifier: BSD-2-Clause OR LGPL-2.1