Add a small binary executable that will be invoked to perform privileged operations, e.g. bpf(2), in behalf of BEAM.
That way this helper executable can be given elevated capabilities instead of the BEAM executable, making things much safer in the long term.

• Acknowledge ebpf_asm
• Add portability section (ebpf_user only works on Linux by definition, the rest is fully portable)

The current (initial, v0.1) API is very familiar to those who know eBPF, but it isn't very idiomatic for Erlang programmers.
For instance, interaction with eBPF maps could be made a lot more familiar for Erlangers if it was modeled after the OTP maps module.

I want to fix that for v0.2. This library is meant to be used by Erlang programmers, so a familiar API is a priority.
Of course, the API should also be as stable as possible, so whatever ends up in v0.2 should be future proof.
Although it's still a minor version the goal is for v0.2 to implement a minimal API that will not break in later versions.

Add a Status section etc.

We should add an option to ebpf_lib:verify to choose the error buffer size, rather than arbitrarily setting it to 4096.
Also, when the error is not eacces (e.g. encoding problem) we should report the errno rather than an empty error report string.

This is a big one, so we should start with something small.
At the very least ebpf_user:attach/2 needs to support kprobe and tracepoint program types.

add NIFs and an API to create, update and query eBPF maps.

Is there any reason to do not link directly the libbpf?

Currently it is the users responsibility to close(2) eBPF map and program file descriptors via ebpf_{maps,user}:close/1.
It would be safer and more convenient if these FDs were to close automatically when no longer needed.
There easiest solution would be to use Erlang NIF "resources" for maps/programs instead just passing an integer FD back to BEAM.
NIF resources can have a destructor-like callback that is called from the garbage collector when the resource is no longer in use, which is where we can close the FD.

Another path would be to drop the NIFs entirely and use an Erlang port driver to represent maps/programs. That would allow for closing the FDs when the owner Erlang process of the map/program dies.

ebpf_lib:disassemble/1 should return some semantic meaning bearing format, rather than the numeric value of eBPF opcodes.

Currently ebpf_kern allows you to write eBPF programs, but it doesn't make it particularly easy or Erlang-y.
ebpf should supply some higher level API for constructing eBPF programs.

I think that the best solution would be having a fun2bpf parse-transform that takes a literal Erlang fun and outputs a sequence of bpf_instructions, but there are a few steps to cross to get there.
For starters it would be nice to have ebpf_kern functions for more common eBPF routines, like loading a value from a map to a specific register, or branching without having to count instructions for the jmp instruction.

• Write a NIF to attach eBPF XDP programs to interface
• Expose the functionality through a proper interface

Make sure that the documentation is clear and consistent (it currently isn't), and add links between sections where needed

• ebpf_user
• ebpf_kern
• ebpf_asm
• overview page?

EDIT:
ebpf_user documentation was updated in #30
ebpf_kern was updated in #31

stdlib has maps:take/2, we should have an equivalent ebpf_maps:take/2 for eBPF map.
This can possibly be implemented by using the BPF_MAP_LOOKUP_AND_DELETE_ELEM command to bpf(2).

Edit: it appears that Linux only supports BPF_MAP_LOOKUP_AND_DELETE_ELEM for queue and stack typed maps.
We can use implement take/2 with get/2 and remove/2 for other types of maps

• ebpf_user - verify/2, verify/3, update_map_element/4, lookup_map_element/4, delete_map_element/2, get_map_next_key/2, attach_xdp/2
• ebpf_kern
• ebpf_asm (pretty much covered, rebar3 proper --cover has it at 100%)