A library to interact with BPF kernel state.
Just simple, pure idiomatic Rust-based bindings to manage user-space state
necessary for interacting with the kernel system. Some little helpers are added
but not beyond the minimalism (avoids generics or extra dependencies).
The name is bacronym for:
> A BPF InterFace Foundation
## Goals
In decreasing order of priority.
* Safer than direct system calls
* Pure Rust code, no C dependency
* Minimal dependencies for OS interaction
* Efficient
Non-Goals:
* Replacement for `libbpf`
* A C interface, to be re-evaluated later
* An `async` style of implementation. It should be possible to achieve all
functionality with synchronous code. However, optional concurrency may be
introduced with `async` where efficient.
* Binary analysis and manipulation of BPF programs
## Implementation
Note that the implementation does _not_ need link directly against any `libc`
functions. Rather, it defines an expected interface in terms of free C
functions (`sys::SysVTable`). The caller can fill it with functions loaded
statically or dynamically from a linker but also with another equivalent
implementation. Unfortunately, the data type definitions will have to be
compatible with the platform `libc` in both cases, but it is a start to avoid
the hell of `LD_PRELOAD` as a stupid, global mechanism for overwriting them.
## Motivation
Depending on `libbpf` is quite heavy when only a fraction of it is needed. In
particular, connecting together networking functionality does not depend on
writing BPF. Also, the library is riddled with C-isms:
* unknown or highly implicit thread-safety
* synchronous resources opened and closed in rapid succession just to hide that
resource management complexity from the caller. No really, a new netlink
socket is created, configured, loop polled and closed for literally each
`libbpf_netlink_send_recv` that's hidden in _a lot_ of operations.
* Code that looks like so:
```c
static int libbpf_netlink_send_recv(...) {
req->nh.nlmsg_seq = time(NULL);
```
They are fucking with us, no?