Hello Alan, On 8/1/24 10:17, Alan Maguire wrote: > 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.
Thanks a lot for the additional details, much appreciated :) -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
