Feature Request: Make aya::obj API public to allow usage with different runtime #473
Comments
|
This has come up a couple of times before. I think we could split the linking/relocation code as part of a separate If you wanted to give this a go I'd be happy to review! |
|
I would love to see that happening. Having proper rbpf support would let us to unit test and debug eBPF programs. And I agree that we could move things out to a new |
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Dec 27, 2022
Aya::obj depends on bindgen generated files, and we start by migrating bindgen generated files. This commit adds the new aya-obj crate to the workplace and migrates generated files into the crate. We use core instead of std in an effort to make the final crate no_std. Bindgen was run against libbpf v1.0.1. Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Dec 27, 2022
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Dec 27, 2022
Aya::obj depends on bindgen generated files, and we start by migrating bindgen generated files. This commit adds the new aya-obj crate to the workplace and migrates generated files into the crate. We use core instead of std in an effort to make the final crate no_std. Bindgen was run against libbpf v1.0.1. Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Dec 27, 2022
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Dec 28, 2022
Types relevant to maps are moved into aya_obj::maps. Some members are marked `pub(crate)` again. Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Jan 2, 2023
Aya::obj depends on bindgen generated files, and we start by migrating bindgen generated files. This commit adds the new aya-obj crate to the workplace and migrates generated files into the crate. We use core instead of std in an effort to make the final crate no_std. Bindgen was run against libbpf v1.0.1. Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Jan 2, 2023
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: aya-rs#473
yesh0
added a commit
to yesh0/aya
that referenced
this issue
Jan 2, 2023
Types relevant to maps are moved into aya_obj::maps. Some members are marked `pub(crate)` again. Refs: aya-rs#473
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There exists some user-space runtime for eBPF programs, like rbpf. However, taking rbpf for an example, it only accepts fully relocated raw eBPF bytecode (similar to BPF_PROG_LOAD in
bpf(2)) and does not support loading programs compiled into a.oobject.It really helps if Aya could make its
aya::objAPI public, so that users of backends other than Linux kernel eBPF runtime can benefit from its.oloading and relocation capabilities.The text was updated successfully, but these errors were encountered: