mirror/xdp-project-bpf-examples
1
0
Fork 0
mirror of https://github.com/xdp-project/bpf-examples.git synced 2024-05-06 15:54:53 +00:00
Code Issues Projects Releases Wiki Activity

Add toplevel README describing project

Browse Source 
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
This commit is contained in:
Jesper Dangaard Brouer
2021-02-09 19:32:41 +01:00
parent 23ae3dcf45
commit 0264295d67
2 changed files with 15 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
README.md Normal file
View File

@@ -0,0 +1,14 @@
# Practical BPF examples
This git repository contains a diverse set of **practical BPF examples** that
solve (or demonstrate) a specific use-case using BPF.
It is meant to ease doing **rapid prototyping and development**, writing C-code
BPF programs using libbpf. The goal is to make is **easier for developers** to
get started coding.
Most developers struggle to get a working BPF build environment. The repo
enviroment makes it easy to build/compile BPF programs by doing the necessary
libbpf setup transparently and detect missing compile dependencies (via the
(configure)[configure] script). It is a declared goal to **make BPF programming
more consumable** by detecting and reporting issues (when possible).

2
headers/README.md
View File

@@ -10,7 +10,7 @@ For example [bpf/compiler.h](bpf/compiler.h) contains practical compile macros
like `READ_ONCE` and `WRITE_ONCE` with verifier workarounds via like `READ_ONCE` and `WRITE_ONCE` with verifier workarounds via
`bpf_barrier()`. And the `likely()` + `unlikely()` annotations. `bpf_barrier()`. And the `likely()` + `unlikely()` annotations.
The include file [linux/bpf.h](linux/bpf.h) is the more central file that all The include file [linux/bpf.h](linux/bpf.h) is the most central file that all
BPF (kernel-side) programs include. It is maintained in this directory, BPF (kernel-side) programs include. It is maintained in this directory,
because this project knows what BPF features it uses, which makes the update because this project knows what BPF features it uses, which makes the update
cycle tied to the project itself. We prefer not to depend on the OS distro cycle tied to the project itself. We prefer not to depend on the OS distro