Following the lead of crates like tokio and nix, we now annotate APIs
that require optional features. This helps in cases where a user wants
to have an `AsyncPerfEventArray` which is documented on crates.io, but
it's not obvious that you have to enable the `async` feature.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
We often need to wait a bit until the program or link gets unloaded
after dropping.
Also, using a macro makes it clear in which particular test the panic
happened.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
libbpf 1.0 doesn't support multimaps defined in `maps` section, it
supports only BTF maps.
At the same time, we already test multimaps loading with the Rust
example (`integration-ebpf/src/bpf/map_test.rs`), so we can just remove
the failing C test.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
`override_syscall` performs integer-to-pointer conversion. This is
considered harmful on the newest Rust nightly which provides
`ptr::from_exposed_addr`, but there is no other way on Rust stable than
doing `as *const T`, which is what miri is unhappy about.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Add BpfLoader::set_max_entries, which sets the max_entries for the
specified map, as the load-time option.
The max_entries set at map initialization in the ebpf component can be
overwritten by this method called on the userspace component.
If you want to set max_entries for multiple maps in an ebpf component,
you can do so by calling set_max_entries in the form of a method chain.
Fixes: #308
Refs: #292
Miri took issue about using slice::from_raw_parts without checking for
alignment. Instead, we can simply convert to a [u8;16] into a [u16;8] by
iterating in chunks of 2 and bitshifting (remembering that these arrays
are in network-endian order).
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Add `from_pinned` to allow loading BPF maps
from pinned points in the bpffs and
`from_fd` to allow loading BPF maps from
RawFds aquired via some other means eg
a unix socket.
These functions return an
aya::Map which has not been used previously
but will be the future abstraction once
all bpf maps are represented as an enum.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
This commit fixes a bug and adds some missing lifecycle APIs.
1. Adds PinnedLink::from_path to create a pinned link from bpffs
2. Adds From<PinnedLink> for FdLink to allow for ^ to be converted
3. Adds From<FdLink> for XdpLink
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Files changed:\nM aya/src/generated/linux_bindings_aarch64.rs
M aya/src/generated/linux_bindings_armv7.rs
M aya/src/generated/linux_bindings_riscv64.rs
M aya/src/generated/linux_bindings_x86_64.rs
Files changed:\nM aya/src/generated/btf_internal_bindings.rs
M aya/src/generated/linux_bindings_aarch64.rs
M aya/src/generated/linux_bindings_armv7.rs
M aya/src/generated/linux_bindings_riscv64.rs
M aya/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/aarch64/helpers.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/helpers.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/helpers.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/helpers.rs
This change separates the previous `SkBuffContext` into three structs:
* `SkBuff` which is a wrapper around `__sk_buff` which contains all
possible methods operating on it.
* `SkBuffContext` which is a program context for programs which
**cannot** access `__sk_buff` directly and instead can only use
`load_bytes`.
* `TcContext` which is a classifier context which can access `__sk_buff`
directly, hence exposes `data` and `data_end`.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
abhijeetbhagat
Dave Tucker
Michal Rostecki
Alessandro Decina
aztecher
Andrew Stoycos
conectado
dave-tucker