Allow to define programs as public functions (even in library crates)
and then import them.
For example, we can have library crate with `libfoo/src/lib.rs`
containing:
```rust
pub fn my_xdp_program(ctx: XdpContext) -> u32 {
xdp_action::XDP_PASS
}
```
And then a binary importing it:
```rust
pub use libfoo::my_xdp_program;
```
This way, commonly used eBPF programs can be distributed as lib crates.
Tested with: https://github.com/vadorovsky/aya-examples/tree/main/pub-progs
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
- Rename `new_tc_link` to `attached`
- Simplified example for `attached`
The following was not requested in reviews:
- Moved example from `SchedClassifierLink` tor
`SchedClassifierLink::attached' since we're only showing an
example of that one method
Signed-off-by: Andre Fredette <afredette@redhat.com>
This is the proposed solution for Step 2 of issue #414
“For cases where you have done program.take_link() to manage
ownership of TcLink we need an API similar to PinnedLink::from_pin
that can reconstruct a TcLink”
As long as a user application continues to run after executing
`take_link()`, the `SchedClassifierLink` returned can be used to
detach the program. However, if we want to handle cases where the
application exits or crashes, we need a way to save and reconstruct
the link, and to do that, we also need to know the information
required for the reconstruction -- namely, the `interface`,
`attach_type`, `priority`, and `handle`. The user knows the first
two because they are required to execute `attach()` in the first
place; however, the user will not know the others if they let the
system choose them.
This pr solves the problems by adding an `impl` for
`SchedClassifierLink` with an accessor for `tc_options` and a `new()`
function.
Signed-off-by: Andre Fredette <afredette@redhat.com>
Currently aya will just report a standard outer level
error on failure. Ensure that we also report the inner
error condition back to the user
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
Include all new map types which were included in the last libbpf update
(5d13fd5aca).
Fixes: cb28533e2f ("aya-obj: Update `BPF_MAP_TYPE_CGROUP_STORAGE` name to `BPF_MAP_TYPE_CGRP_STORAGE`")
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Before this chane, the check was always negative if the minor version
was less then 9. So, for example, the smoke test was skipped for kernel
6.1:
```
skipping as 6.1 does not meet version requirement of 5.9
```
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
Simplifiy the relocation tests build process by removing the need for libbpf
at runtime. Its usage is replaced with local `__builtin_*` attributes.
This removes the need for the `LIBBPF_INCLUDE` env variable.
Files changed:
M aya-obj/src/generated/linux_bindings_aarch64.rs
M aya-obj/src/generated/linux_bindings_armv7.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/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
- Set the version number of `aya-obj` to `0.1.0`.
- Update the description of the `aya-obj` crate.
- Add a section in README and rustdoc warning about the unstable API.
This commit adds documentation on how program names are parsed from
section names, as is used by `aya_obj::Object.programs` as HashMap keys,
and updates the examples into using program names.
Alessandro Decina
Michal Rostecki
banditopazzo
Andre Fredette
Andre Fredette
Andrew Stoycos
Matteo Nardi
alessandrod
Shenghui Ye