aya is missing query features

[seanyoung]

libbpf has the bpf_prog_query() function to get a list of the all attached programs; it is also possible to deattach them and get their names.

I am currently re-writing ir-keytable in rust https://github.com/seanyoung/ir (early stages). For aya to be useful for this work, it would require this functionality.

[alessandrod]

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.

[seanyoung]

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.

[alessandrod]

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 Links 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 :)

[alessandrod]

@seanyoung are you planning to do or have you done any work on this? Otherwise I might get to it next week

[seanyoung]

@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.

[tamird]

Looks like #32 was meant to close this.