mirror of https://github.com/aya-rs/aya
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
5750c3ef7a
This commit adds PinnedProgram which allows the creation of a Program from a path on bpffs. This is useful to be able to call `attach` or other APIs for programs that are already loaded to the kernel. Unfortunately figuring out the concrete type of program is hard given the information in the kernel so this may not work for all program types. Signed-off-by: Dave Tucker <dave@dtucker.co.uk> |
3 years ago | |
|---|---|---|
| .. | ||
| integration-ebpf | 3 years ago | |
| integration-test | 3 years ago | |
| integration-test-macros | 3 years ago | |
| .gitignore | 3 years ago | |
| README.md | 3 years ago | |
| run.sh | 3 years ago | |
README.md
Aya Integration Tests
The aya integration test suite is a set of tests to ensure that common usage behaviours work on real Linux distros
Prerequisites
Linux
To run locally all you need is:
- Rust nightly
- A checkout of
libbpf cargo install bpf-linkerbpftool
Other OSs
- A POSIX shell
- A checkout of
libbpf rustup target add x86_64-unknown-linux-muslcargo install bpf-linker- Install
qemuandcloud-init-utilspackage - or any package that providescloud-localds
Usage
From the root of this repository:
Native
cargo xtask integration-test --libbpf-dir /path/to/libbpf
Virtualized
./test/run.sh /path/to/libbpf
Writing a test
Tests should follow these guidelines:
- Rust eBPF code should live in
integration-ebpf/${NAME}.rsand included inintegration-ebpf/Cargo.toml - C eBPF code should live in
integration-test/src/bpf/${NAME}.bpf.c. It's automatically compiled and made available as${OUT_DIR}/${NAME}.bpf.o. - Any bytecode should be included in the integration test binary using
include_bytes_aligned! - Tests should be added to
integration-test/src/test - You may add a new module, or use an existing one
- Integration tests must use the
#[integration_test]macro to be included in the build - Test functions should return
anyhow::Result<()>since this allows the use of?to return errors. - You may either
panic!when an assertion fails orbail!. The former is preferred since the stack trace will point directly to the failed line.