On Tue, Mar 15, 2022 at 1:22 AM Grant Seltzer Richman <grantseltzer@xxxxxxxxx> wrote: > > Hi there, > > If I call `bpf_map_create()` successfully I'll have a file descriptor > and not a `struct bpf_map`. This stifles me from using a lot of the > `bpf_map__` API functions, for example `bpf_map__pin()`. What's the > reason for this? Is there a way to get a `struct bpf_map` that I'm > missing? > bpf_map_create() is a low-level libbpf API. It does create a map and returns FD. But it is not "integrated" with struct bpf_map APIs, which are so-called high-level libbpf APIs. bpf_object/bpf_map/bpf_program and related APIs are high-level APIs and they expect ELF BPF object file to declaratively define everything. You can use low-level APIs by getting FDs from high-level bpf_map/bpf_program using bpf_map__fd() and bpf_program__fd(), but constructing bpf_map from FD isn't easy or straightforward and should be avoided, if possible. But one way to do this is to still declaratively define map in BPF object file, but then do bpf_map__reuse_fd() to substitute already created map by FD. This way libbpf won't create another map, it will just use your FD. But definitions of maps have to be compatible in terms of key/value sizes, max_entries, etc. In short: it's painful. As a bit of aside, I do think we are missing high-level APIs to work with bpf_map elements, something like bpf_map__lookup_elem() and bpf_map__update_elem() has been on my mind for a while, but I haven't gotten time to get to it. It would further minimize the need to drop down to low-level APIs. > Thanks so much, > Grant Seltzer > > P.s. been a while since I've worked on adding docs, but I will finally > be getting back to it! Great, looking forward!
