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.
dc31e11691
This commit moves the aya-log projects from the subtree and adds them to the main cargo workspace. It also brings the BPF crates into the workspace and moves the macro crates up a level since they aren't BPF code. Miri was disabled for aya-bpf as the previous config wasn't actually checking anything. CI, clippy, fmt and release configurations have all been adjusted appropriately. CI was not properly running for other supported arches which was also ixed here. Signed-off-by: Dave Tucker <dave@dtucker.co.uk> |
2 years ago | |
|---|---|---|
| .. | ||
| integration-ebpf | 2 years ago | |
| integration-test | 2 years ago | |
| integration-test-macros | 2 years ago | |
| .gitignore | 2 years ago | |
| README.md | 2 years ago | |
| run.sh | 2 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.