Comments (6)
The query I'm thinking should probably be a helper function in the aya::programs
, and be something like
fn query<T: AsRawFd>(target_fd: T, attach_type: XXX, flags: u32) -> Result<(Vec<u32>, u32), io::Error>
Where the result is a Vec
of prog ids and the attach flags. As for the XXX
type , we could re-export crate::generated::bpf_attach_type
as aya::programs::AttachType
for now, or we could create a new enum and keep it in sync, bpf_attach_type
doesn't change that often anyway.
To get the name then you'd use a separate syscall right?
As for detaching, I'm not sure yet what we could do. I know I want to add a forget()
method to the Link
trait (related to your other PR), but haven't thought about what the API to detach an arbitrary fd/type would look like.
from aya.
I do wonder if it is possible to create a higher level of abstraction than (Vec<u32>, u32)
. I think it would be nicer if we returned a list of programs, which had a detach()
and info()
method of some sort. struct bpf_prog_info
contains a lot of information, not just the name.
from aya.
Yes you're right, we should definitely create a higher level API. I guess my thinking was that coming up with a higher level interface would probably require some work (see below), so we could start by wrapping the syscall. Now that I've thought about it though, I think I was overthinking it.
Agreed on info()
, we should have it return a type that contains everything useful from struct bpf_prog_info
. And about detach()
, I was thinking that it would be tricky ensuring that it doesn't break things if you have other Link
s laying around, but that's not the case. All the existing Link::detach()
impls already ignore errors on detach. And regardless of what interface we come up with, we need to handle other programs (eg bpftool) potentially detaching our links anyway.
So yeah, this is easier than I first thought :)
from aya.
@seanyoung are you planning to do or have you done any work on this? Otherwise I might get to it next week
from aya.
@alessandrod I had started on this, see my query branch https://github.com/seanyoung/aya/commits/query. The query of programs and their names works, but not detaching or any other field than name.
There are some issues which I haven't figured out yet. This where I am at.
- The query interface is bpf program dependent, for example the query_flags are bpf program/attach dependent, so I think the query interface should exist on the specific program type (e.g. LircMode2)
- The interface for querying the bpf_info is generic and can be shared
- The interface for detaching the program is specific for the program type and should probably be shared with the bpf program specific detach code (for programs which were attached, not found via query interface).
So I was kind of stuck on how to model this. The QueryProgram isn't going to work for detaching, but will work for a generic info querying.
from aya.
Looks like #32 was meant to close this.
from aya.
Related Issues (20)
- Separate BpfContext from BpfSomethingContext HOT 2
- panic: enum relocation index out of bounds
- SockOpsLink is not exported
- XDP_TX isn't putting the packet back in the network.
- AYA tc classifier does not support using tc_classid
- Aya nightly crates HOT 4
- Error: error parsing BPF object: invalid program section `cgroup_skb` HOT 4
- Error: error parsing BPF object HOT 3
- Hashmap is not cleaned on every execution HOT 1
- integration-test: `rust-lld` invoked by `cargo xtask integration-test vm` fails to find libraries
- Dependency Hijacking risk due to Crate Name Change HOT 2
- ebpf obj isn't compatible with libbpf v1.0+
- Instructions on codegen HOT 1
- Add TCX link support
- Error: error relocating function
- Inside `aya-ebpf::programs` some `raw` pointers are having `pub` visibility.
- Bug on system suspend HOT 3
- error: failed to create `BPF_MAP_TYPE_ARRAY_OF_MAPS` of `BPF_MAP_TYPE_RINGBUF` HOT 2
- How about supporting for searching the symbols file from the gnu.debuglink section? HOT 1
- Discord links are expired or no longer valid HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aya.