[−][src]Crate redbpf
RedBPF
This crate provides a build-load-run workflow for eBPF modules. If the
build
cargo feature is enabled, build-specific functionality is available.
You may want to use the redbpf
crate like so:
[build-dependencies]
redbpf = { version = "0.1", features = ["build"] }
[dependencies]
redbpf = "0.1"
For more information about build-specific examples, look at the
documentation for the build
module.
ELF object expectations
The ELF sections loaded by RedBPF should follow the following naming convention:
maps/name
for mapskprobe/function_name
for entry probes forfunction_name
kretprobe/function_name
for return probes forfunction_name
xdp/name
for XDP probes. Names can be anything.socketfilter/name
for socket filters. Names can be anything.
Additionally, as per convention, the following sections should be present in the ELF object:
__u32 _version SEC("version") = 0xFFFFFFFE;
char _license[] SEC("license") = "GPL";
If the license is not GPL, some in-kernel functionality is not available for eBPF modules.
The magic version number is compatible with GoBPF's convention: during
loading it is replaced with the currently running kernel's internal version,
as returned by uname()
.
Modules
cpus | |
sys | |
uname |
Structs
LostSamples | |
Map | Maps are loaded automatically, so you normally do not have to do anything to initialise them after loading an ELF file. |
Module | |
PerfMap | |
Program | You can load an eBPF module, and all the programs in it like so: |
Rel | |
Sample |
Enums
Event | |
LoadError | |
ProgramKind |
Type Definitions
DataPtr | |
MutDataPtr | |
Result | |
VoidPtr |