| commit | 07ccefd32e09590b156b75c3a4f6285d2e5a90b6 | [log] [tgz] |
|---|---|---|
| author | Daniel Müller <deso@posteo.net> | Mon May 23 23:04:25 2022 +0000 |
| committer | Quentin Monnet <qmonnet+github@qoba.lt> | Wed Jun 08 14:43:02 2022 +0100 |
| tree | c0aa216f27feac0115fef56ce5d1c972081cf9f0 | |
| parent | ca1950f29593ff7062c51772fb8a62fd6ff3546f [diff] |
bpftool: Use libbpf_bpf_attach_type_str This change switches bpftool over to using the recently introduced libbpf_bpf_attach_type_str function instead of maintaining its own string representation for the bpf_attach_type enum. Note that contrary to other enum types, the variant names that bpftool maps bpf_attach_type to do not adhere a simple to follow rule. With bpf_prog_type, for example, the textual representation can easily be inferred by stripping the BPF_PROG_TYPE_ prefix and lowercasing the remaining string. bpf_attach_type violates this rule for various variants. We decided to fix up this deficiency with this change, meaning that bpftool uses the same textual representations as libbpf. Supporting tests, completion scripts, and man pages have been adjusted accordingly. However, we did add support for accepting (the now undocumented) original attach type names when they are provided by users. For the test (test_bpftool_synctypes.py), I have removed the enum representation checks, because we no longer mirror the various enum variant names in bpftool source code. For the man page, help text, and completion script checks we are now using enum definitions from uapi/linux/bpf.h as the source of truth directly. Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220523230428.3077108-10-deso@posteo.net
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.
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.
Required:
Optional:
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
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
Additional CFLAGS can be passed to the command line if required. For example, we can create a static build with the following commands (but note that this does not work out-of-the-box when linking with libbfd):
$ cd src $ CFLAGS=--static make
The man pages for bpftool can be built with:
$ cd docs
$ make
They can be installed on the system with:
$ cd docs # make install
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)