On Mon, Dec 09, 2019 at 05:14:23PM -0800, Andrii Nakryiko wrote: > This patch set introduces an alternative and complimentary to existing libbpf > API interface for working with BPF objects, maps, programs, and global data > from userspace side. This approach is relying on code generation. bpftool > produces a struct (a.k.a. skeleton) tailored and specific to provided BPF > object file. It includes hard-coded fields and data structures for every map, > program, link, and global data present. > > Altogether this approach significantly reduces amount of userspace boilerplate > code required to open, load, attach, and work with BPF objects. It improves > attach/detach story, by providing pre-allocated space for bpf_links, and > ensuring they are properly detached on shutdown. It allows to do away with by > name/title lookups of maps and programs, because libbpf's skeleton API, in > conjunction with generated code from bpftool, is filling in hard-coded fields > with actual pointers to corresponding struct bpf_map/bpf_program/bpf_link. > > Also, thanks to BPF array mmap() support, working with global data (variables) > from userspace is now as natural as it is from BPF side: each variable is just > a struct field inside skeleton struct. Furthermore, this allows to have > a natural way for userspace to pre-initialize global data (including > previously impossible to initialize .rodata) by just assigning values to the > same per-variable fields. Libbpf will carefully take into account this > initialization image, will use it to pre-populate BPF maps at creation time, > and will re-mmap() BPF map's contents at exactly the same userspace memory > address such that it can continue working with all the same pointers without > any interruptions. If kernel doesn't support mmap(), global data will still be > successfully initialized, but after map creation global data structures inside > skeleton will be NULL-ed out. This allows userspace application to gracefully > handle lack of mmap() support, if necessary. > > A bunch of selftests are also converted to using skeletons, demonstrating > significant simplification of userspace part of test and reduction in amount > of code necessary. Changes look good to me. Acked-by: Martin KaFai Lau <kafai@xxxxxx> which should not stop the on-going discussion.
