On 31/07/2024 19:53, Alexis Lothoré wrote: > Hello Alan, > > On 7/31/24 19:23, Alan Maguire wrote: >> On 31/07/2024 11:38, Alexis Lothoré (eBPF Foundation) wrote: > > [...] > >>> + pid = getpid(); >>> + if (!ASSERT_OK(bpf_map__update_elem(skel->maps.pidmap, &key, >>> + sizeof(key), &pid, sizeof(pid), 0), >>> + "write pid")) >>> + goto cleanup_progs; >>> + >> >> I think it would be worth using a global variable in the BPF program >> my_pid, and setting skel->bss->my_pid here as other more up-to-date >> tests do (example progs/test_usdt.c, prog_tests/usdt.c). No need for a >> separate map anymore. > > That sounds like a good improvement, thanks for the hint and the example :) I'll > spin a new revision with this, and make sure to use it in my next test > conversion patches too when relevant. > > TBH I am not familiar with global variables usage in ebpf/libbpf, so it is not > clear for me when I should prefer it over classic maps. From some quick search I > feel like it should be the default choice when needing basic controls > knobs/feedback on a bpf program from userspace ? Or maybe it should be used even > more broadly by default ? > Yeah, it's certainly what I use by default, unless I need multiple instances of an object. Under the hood, the BPF skeleton creates single-element array maps for .bss, .data and .rodata sections which contain all the initialized, uninitialized and constant globals in the BPF object and mmaps() them so you can read/update the values in userspace via skel->bss/skel->data without needing a map-related syscalls. >>> + /* trigger the syscall on which is attached the tested prog */ >>> + if (!ASSERT_OK(syscall(__NR_nanosleep, &req, NULL), "nanosleep")) >>> + goto cleanup_progs; >>> + >>> + if (!ASSERT_OK(bpf_map__lookup_elem(skel->maps.cg_ids, &key, >>> + sizeof(key), &kcgid, sizeof(kcgid), >>> + 0), >>> + "read bpf cgroup id")) >>> + goto cleanup_progs; >>> + >> >> ditto here, cg_ids could be a global var cg_id that the bpf prog sets >> and we check here via skel->bss->cg_id. > > ACK, I'll update this too. > Great, thank you! Alan
