search

foniod / redbpf

Rust library for building and running BPF/eBPF modules
Apache License 2.0
1.71k stars 136 forks source link

bpf-sys/libbpf-sys conflict #260

Open kriomant opened 2 years ago

kriomant commented 2 years ago

I try to write eBPF program which redirects some packets to user-space using AF_XDP socket and XSK_MAP. I patched RedBPF to add support for XSK maps. But then I need some crate for working with AF_XDP sockets in user-space. There are several crates available (like afxdp, xsk-rs, etc), but there is problem: RedBPF uses bpf-sys crate and all AF_XDP-wrapping crates use libbpf-sys crate, and they conflict with each other.

So, why does RedBPF uses bpf-sys instead of libbpf-sys, is libbpf-sys not feature-full enough or is it just for historical reasons? It seems RedBPF is the only consumer of bpf-sys. Is there any solution for my problem other than reimplementing AF_XDP support on top of bpf-sys?

rsdy commented 2 years ago

There's no particular reason other than history. I reckon porting would be reasonably simple at this stage (mass-replace?), and actually would be great to be more compatible with the rest of the rust/bpf ecosystem.

rhdxmr commented 2 years ago

I agree that using libbpf directly stems from historical reason. When RedBPF was initiated, there were not enough Rust eco systems for BPF. There was no libbpf-sys or libbpf-rs. I feel sorry that libbpf-sys didn't choose to contribute to bpf-sys which already existed when they started their own project. Haha just kidding.

Few years ago BCC was de facto standard and it provides better functionality than libbpf. So it was natural to depend on BCC when RedBPF was initiated and it actually depended on BCC. But last year I removed the dependency of BCC from RedBPF. I think it was enough but I didn't come up with removing direct dependency of libbpf.

I also think it is desirable to prefer libbpf-sys than libbpf. And it might be nice if bpf-sys was created as a separate project with the name libbpf-sys in 2018. Haha.