On Wed, Apr 14, 2021 at 7:26 PM Grant Seltzer Richman <grantseltzer@xxxxxxxxx> wrote: > > As I understand it, accessing and setting read only global variables > from a userspace control program through libbpf can only happen when > importing a BPF skeleton. Things like `bpf_object__find_map_by_name()` > are exposed but the name of this map is internal and > `internal_map_name()` is as well. Traversing through the maps array > via bpf_object directly doesn't seem possible either. Not really. See bpf_object__for_each_map() macro and bpf_map__is_internal() API, both of which are public. As for the name, it's also sort of part of API, though I want to fix them in libbpf 1.0 (they should be named .rodata, .data, .bss). So you can definitely either find the map with iteration or by knowing how the name is generated. Then do mmap() and using BTF you'll know each variable's offset and size. No magic, just some code to do this, which is what is done by bpftool for skeletons (bpftool is a completely external user of libbpf in this case, no private APIs are involved). > > Why is this feature only available through generating a skeleton? > Should there be differences in supported functionality between using a > skeleton and using libbpf directly?
