Add libbpf-based tools #2755
Merged
Add libbpf-based tools #2755
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Check in bpftool binary to be used for BPF skeleton generation for libbpf-based tools. Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Check in vmlinux.h generated from Linux 5.5 version with default config. This is used from libbpf-based tools. Signed-off-by: Andrii Nakryiko <andriin@fb.com>
anakryiko
requested review from
4ast,
brendangregg,
drzaeus77,
goldshtn and
yonghong-song
as code owners
|
Thanks, I'll check it out, and have a go at porting some myself (like execsnoop(8), opensnoop(8), biosnoop(8), biolatency(8), ...). I like to preserve the history of the tools we use. Could runqslower.c have a comment line at the top to say something like: // Based on runqslower(8) from BCC by Ivan Babrou.
// 11-Feb-2020 Andrii Nakryiko Created This.And the man/man8/runqslower.8 file could say something like: |
|
Sounds good, will add! |
… tool Add runqslower as a first tool converted from BCC to libbpf, utilizing BPF CO-RE (Compile Once - Run Everywhere) approach and BPF skeleton for interfacing with BPF programs. Current set up is Makefile based and is set up in such a way as to enable easy addition for more tools, based on a simple and convenient naming pattern. General build infrastructure takes case of BPF skeleton generation, tracking dependencies, clean up, etc. Signed-off-by: Andrii Nakryiko <andriin@fb.com>
anakryiko
force-pushed
the
libbpf-based-tools
branch
from
d4fcb85 to
e1496e1
Compare
|
Added history, updated man page. Added |
|
[buildbot, test this please] |
|
Thanks! This is good enough for folks to start experiments! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With BPF Compile Once - Run Everywhere (CO-RE), global variables, BPF skeleton, and other BPF features developed over last year, it's now feasible to build equivalents of BCC tools without the need to perform BPF code compilation in runtime and without dependency on installed kernel-devel package. This change adds a first such tool (runqslower), converted from its Python origin to a pure C-based tool, using BPF CO-RE. It also sets up a build flow to simplify adding/converting more such tools easily for people willing to help.
It seems like a good idea to keep such tools close to their progenitors and let users choose what works best for them: BCC-based tools are great for experimentation and quick prototyping and customizing to ad-hoc user needs, but sometimes require a high toll w.r.t. runtime resource usage (Clang/LLVM/Python dependency) and assumptions about kernel headers availability. On the other hand, libbpf- and CO-RE-based tools are small, fast and with almost no extra dependencies, but rely on more recent kernel versions. Having both will help better address user needs and will hopefully grow user community further.
See README.md for some more details on a build setup and conventions.