| commit | 45244fc5d11978d435d9458a47163c2e31905e6b | [log] [tgz] |
|---|---|---|
| author | Andrii Nakryiko <andrii@kernel.org> | Wed Jan 19 22:05:28 2022 -0800 |
| committer | Quentin Monnet <qmonnet+github@qoba.lt> | Mon Jan 24 17:43:27 2022 +0000 |
| tree | f58fcc0a3b0828e821d8ba7ad2a8f32255e68a8f | |
| parent | 7b2cd3b42d13516233e37e16ee617d5c404ab87b [diff] |
libbpf: deprecate legacy BPF map definitions
Enact deprecation of legacy BPF map definition in SEC("maps") ([0]). For
the definitions themselves introduce LIBBPF_STRICT_MAP_DEFINITIONS flag
for libbpf strict mode. If it is set, error out on any struct
bpf_map_def-based map definition. If not set, libbpf will print out
a warning for each legacy BPF map to raise awareness that it goes away.
For any use of BPF_ANNOTATE_KV_PAIR() macro providing a legacy way to
associate BTF key/value type information with legacy BPF map definition,
warn through libbpf's pr_warn() error message (but don't fail BPF object
open).
BPF-side struct bpf_map_def is marked as deprecated. User-space struct
bpf_map_def has to be used internally in libbpf, so it is left
untouched. It should be enough for bpf_map__def() to be marked
deprecated to raise awareness that it goes away.
bpftool is an interesting case that utilizes libbpf to open BPF ELF
object to generate skeleton. As such, even though bpftool itself uses
full on strict libbpf mode (LIBBPF_STRICT_ALL), it has to relax it a bit
for BPF map definition handling to minimize unnecessary disruptions. So
opt-out of LIBBPF_STRICT_MAP_DEFINITIONS for bpftool. User's code that
will later use generated skeleton will make its own decision whether to
enforce LIBBPF_STRICT_MAP_DEFINITIONS or not.
There are few tests in selftests/bpf that are consciously using legacy
BPF map definitions to test libbpf functionality. For those, temporary
opt out of LIBBPF_STRICT_MAP_DEFINITIONS mode for the duration of those
tests.
[0] Closes: https://github.com/libbpf/libbpf/issues/272
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20220120060529.1890907-4-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
- .github/
- bash-completion/
- docs/
- include/
- scripts/
- src/
- libbpf
- .gitmodules
- BPF-CHECKPOINT-COMMIT
- CHECKPOINT-COMMIT
- LICENSE
- LICENSE.BSD-2-Clause
- LICENSE.GPL-2.0
- README.md
bpftool
This is a mirror of bpf-next Linux source tree's tools/bpf/bpftool directory, plus its few dependencies from under kernel/bpf/, and its supporting header files.
All the gory details of syncing can be found in scripts/sync-kernel.sh script.
Some header files in this repo (include/linux/*.h) are reduced versions of their counterpart files at bpf-next's tools/include/linux/*.h to make compilation successful.
BPF/bpftool usage and questions
Please check out the manual pages for documentation about bpftool. A number of example invocations are also displayed in this blog post.
All general BPF questions, including kernel functionality, bpftool features and usage, should be sent to bpf@vger.kernel.org mailing list. You can subscribe to it here and search its archive here. Please search the archive before asking new questions. It very well might be that this was already addressed or answered before.
bpf@vger.kernel.org is monitored by many more people and they will happily try to help you with whatever issue you have. This repository's PRs and issues should be opened only for dealing with issues pertaining to specific way this bpftool mirror repo is set up and organized.
Dependencies
Required:
- libelf
- zlib
Optional:
- libbfd (for dumping JIT-compiled program instructions)
- libcap (for better feature probing)
- kernel BTF information (for profiling programs or showing PIDs of processes referencing BPF objects)
- clang/LLVM (idem)
Build 
Initialize libbpf submodule
This repository uses libbpf as a submodule. You can initialize it when cloning bpftool:
$ git clone --recurse-submodules https://github.com/libbpf/bpftool.git
Alternatively, if you have already cloned the repository, you can initialize the submodule by running the following command from within the repository:
$ git submodule update --init
Build bpftool
To build bpftool:
$ cd src
$ make
To build and install bpftool on the system:
$ cd src # make install
Building bpftool in a separate directory is supported via the OUTPUT variable:
$ mkdir /tmp/bpftool $ cd src $ OUTPUT=/tmp/bpftool make
Most of the output is suppressed by default, but detailed building logs can be displayed by passing V=1:
$ cd src $ make V=1
Build bpftool's man pages
The man pages for bpftool can be built with:
$ cd docs
$ make
They can be installed on the system with:
$ cd docs # make install
License
This work is dual-licensed under the GNU GPL v2.0 (only) license and the BSD 2-clause license. You can choose between one of them if you use this work.
SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)