I have been down a rabbit hole of cleaning up the aya error types 😅 Most of the important changes are in `errors.rs`. TL;DR Current exposed types are: - `EbpfError` - `ProgramError` - `MapError` - `LinkError` - `PerfBufferError` - `SysError` Honestly I'm still thinking about how we could collapse those types. Either into a single type, or at least fewer than we expose today. Within each of those types, I've tried to remove any invariants that don't have any business being public (e.g if a syscall fails with -EINVAL, there is nothing at runtime you can do about it other than bailing). 👆 (and the spaghetti of errors depending on other errors) are replaced by an `Other` invariant that's a Box<dyn std::error::Error>. There are still some `pub(crate) XInternalError` types, but these are used only to make nice error messages. This could plausibly be replaced with anyhow/context etc.. But I've left it as-is for now. Signed-off-by: Dave Tucker <dave@dtucker.co.uk> |
8 months ago | |
---|---|---|
.cargo | 9 months ago | |
.github | 8 months ago | |
.vim | 3 years ago | |
.vscode | 2 years ago | |
assets | 3 years ago | |
aya | 8 months ago | |
aya-ebpf-macros | 8 months ago | |
aya-log | 8 months ago | |
aya-log-common | 8 months ago | |
aya-log-ebpf-macros | 1 year ago | |
aya-log-parser | 1 year ago | |
aya-obj | 8 months ago | |
aya-tool | 1 year ago | |
ebpf | 8 months ago | |
init | 1 year ago | |
test | 8 months ago | |
xtask | 8 months ago | |
.gitignore | 2 years ago | |
.gitmodules | 2 years ago | |
.markdownlint-cli2.yaml | 1 year ago | |
.mergify.yml | 1 year ago | |
.taplo.toml | 1 year ago | |
CODE_OF_CONDUCT.md | 2 years ago | |
CONTRIBUTING.md | 2 years ago | |
Cargo.toml | 8 months ago | |
LICENSE-APACHE | 4 years ago | |
LICENSE-MIT | 4 years ago | |
README.md | 1 year ago | |
netlify.toml | 2 years ago | |
release.toml | 1 year ago | |
rustfmt.toml | 2 years ago |
README.md
API Documentation
Community
Join the conversation on Discord to discuss anything related to Aya or discover and contribute to a list of Awesome Aya projects.
Overview
eBPF is a technology that allows running user-supplied programs inside the Linux kernel. For more info see What is eBPF.
Aya is an eBPF library built with a focus on operability and developer experience. It does not rely on libbpf nor bcc - it's built from the ground up purely in Rust, using only the libc crate to execute syscalls. With BTF support and when linked with musl, it offers a true compile once, run everywhere solution, where a single self-contained binary can be deployed on many linux distributions and kernel versions.
Some of the major features provided include:
- Support for the BPF Type Format (BTF), which is transparently enabled when supported by the target kernel. This allows eBPF programs compiled against one kernel version to run on different kernel versions without the need to recompile.
- Support for function call relocation and global data maps, which allows eBPF programs to make function calls and use global variables and initializers.
- Async support with both tokio and async-std.
- Easy to deploy and fast to build: aya doesn't require a kernel build or compiled headers, and not even a C toolchain; a release build completes in a matter of seconds.
Example
Aya supports a large chunk of the eBPF API. The following example shows how to
use a BPF_PROG_TYPE_CGROUP_SKB
program with aya:
use std::fs::File;
use aya::Ebpf;
use aya::programs::{CgroupSkb, CgroupSkbAttachType};
// load the BPF code
let mut ebpf = Ebpf::load_file("ebpf.o")?;
// get the `ingress_filter` program compiled into `ebpf.o`.
let ingress: &mut CgroupSkb = ebpf.program_mut("ingress_filter")?.try_into()?;
// load the program into the kernel
ingress.load()?;
// attach the program to the root cgroup. `ingress_filter` will be called for all
// incoming packets.
let cgroup = File::open("/sys/fs/cgroup/unified")?;
ingress.attach(cgroup, CgroupSkbAttachType::Ingress)?;
Contributing
Please see the contributing guide.
License
Aya is distributed under the terms of either the MIT license or the Apache License (version 2.0), at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this crate by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.