Commit Graph

6 Commits (53c59aed5e0bc4b9ee5563ec8751f727c7e5371e)

Author SHA1 Message Date
Thomas Eizinger 53c59aed5e
workspace: include eBPF crates in default-members
Being able to compile the eBPF crates for the host architecture is
useful because it allows `cargo build` and `cargo test` to "just work".

To achieve that, we feature-gate `no_std` and `no_main` on the bpf
target architecture.
Thomas Eizinger ef181058b0
fix: only include panic-handler on bpf target
Dave Tucker 3078e5aba0 chore: Fix clippy panic_handler warnings
Working with aya in vscode will currently show a number of warnings
along the lines of:

```
found duplicate lang item `panic_impl`
the lang item is first defined in crate `std` (which `aya` depends on)
...
second definition in the local crate (`bpf_probe_read`)
```

This comes from feature unification.
integration-test requires the integration-common user feature, which
requires aya, which in turn brings in std.

For this same reason we avoid running clippy across the whole workspace.

We can avoid this issue by using the panic handler from the another
crate, which implements the same loop {} panic handler we use today.
It seems rustc is happy to conditionally link the panic handler
from an external crate without issuing warnings.

Therefore, we add our own crate - ebpf-panic - for this purpose.

Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Tamir Duberstein e0c4948e36 Extract integration-common for shared types
Dave Tucker 41c61560ea chore(aya-ebpf): Rename bpf -> ebpf
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Andrew Werner e2cf734490 aya: Implement RingBuf
This implements the userspace binding for RingBuf.

Instead of streaming the samples as heap buffers, the process_ring
function takes a callback to which we pass the event's byte region,
roughly following [libbpf]'s API design. This avoids a copy and allows
marking the consumer pointer in a timely manner.

[libbpf]: https://github.com/libbpf/libbpf/blob/master/src/ringbuf.c

Additionally, integration tests are added to demonstrate the usage
of the new APIs and to ensure that they work end-to-end.

Co-authored-by: William Findlay <william@williamfindlay.com>
Co-authored-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>