On Mon, Dec 09, 2019 at 05:14:34PM -0800, Andrii Nakryiko wrote:
> Add `bpftool gen skeleton` command, which takes in compiled BPF .o object file
> and dumps a BPF skeleton struct and related code to work with that skeleton.
> Skeleton itself is tailored to a specific structure of provided BPF object
> file, containing accessors (just plain struct fields) for every map and
> program, as well as dedicated space for bpf_links. If BPF program is using
> global variables, corresponding structure definitions of compatible memory
> layout are emitted as well, making it possible to initialize and subsequently
> read/update global variables values using simple and clear C syntax for
> accessing fields. This skeleton majorly improves usability of
> opening/loading/attaching of BPF object, as well as interacting with it
> throughout the lifetime of loaded BPF object.
>
> Generated skeleton struct has the following structure:
>
> struct <object-name> {
> /* used by libbpf's skeleton API */
> struct bpf_object_skeleton *skeleton;
> /* bpf_object for libbpf APIs */
> struct bpf_object *obj;
> struct {
> /* for every defined map in BPF object: */
> struct bpf_map *<map-name>;
> } maps;
> struct {
> /* for every program in BPF object: */
> struct bpf_program *<program-name>;
> } progs;
> struct {
> /* for every program in BPF object: */
> struct bpf_link *<program-name>;
> } links;
> /* for every present global data section: */
> struct <object-name>__<one of bss, data, or rodata> {
> /* memory layout of corresponding data section,
> * with every defined variable represented as a struct field
> * with exactly the same type, but without const/volatile
> * modifiers, e.g.:
> */
> int *my_var_1;
> ...
> } *<one of bss, data, or rodata>;
> };
>
> This provides great usability improvements:
> - no need to look up maps and programs by name, instead just
> my_obj->maps.my_map or my_obj->progs.my_prog would give necessary
> bpf_map/bpf_program pointers, which user can pass to existing libbpf APIs;
> - pre-defined places for bpf_links, which will be automatically populated for
> program types that libbpf knows how to attach automatically (currently
> tracepoints, kprobe/kretprobe, raw tracepoint and tracing programs). On
> tearing down skeleton, all active bpf_links will be destroyed (meaning BPF
> programs will be detached, if they are attached). For cases in which libbpf
> doesn't know how to auto-attach BPF program, user can manually create link
> after loading skeleton and they will be auto-detached on skeleton
> destruction:
>
> my_obj->links.my_fancy_prog = bpf_program__attach_cgroup_whatever(
> my_obj->progs.my_fancy_prog, <whatever extra param);
>
> - it's extremely easy and convenient to work with global data from userspace
> now. Both for read-only and read/write variables, it's possible to
> pre-initialize them before skeleton is loaded:
>
> skel = my_obj__open(raw_embed_data);
> my_obj->rodata->my_var = 123;
This will be very useful. I can think of one immediate use on this
for my current TCP work.
> my_obj__load(skel); /* 123 will be initialization value for my_var */
>
