Alexei Starovoitov <ast@xxxxxx> writes: > On 3/27/20 3:26 PM, Toke Høiland-Jørgensen wrote: >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >>> On Fri, Mar 27, 2020 at 5:58 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >>>> >>>> For internal maps (most notably the maps backing global variables), libbpf >>>> uses an internal mmaped area to store the data after opening the object. >>>> This data is subsequently copied into the kernel map when the object is >>>> loaded. >>>> >>>> This adds a getter for the pointer to that internal data store. This can be >>>> used to modify the data before it is loaded into the kernel, which is >>>> especially relevant for RODATA, which is frozen on load. This same pointer >>>> is already exposed to the auto-generated skeletons, so access to it is >>>> already API; this just adds a way to get at it without pulling in the full >>>> skeleton infrastructure. >>>> >>>> Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> >>>> --- >>>> v2: >>>> - Add per-map getter for data area instead of a global rodata getter for bpf_obj >>>> >>>> tools/lib/bpf/libbpf.c | 9 +++++++++ >>>> tools/lib/bpf/libbpf.h | 1 + >>>> tools/lib/bpf/libbpf.map | 1 + >>>> 3 files changed, 11 insertions(+) >>>> >>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c >>>> index 085e41f9b68e..a0055f8908fd 100644 >>>> --- a/tools/lib/bpf/libbpf.c >>>> +++ b/tools/lib/bpf/libbpf.c >>>> @@ -6756,6 +6756,15 @@ void *bpf_map__priv(const struct bpf_map *map) >>>> return map ? map->priv : ERR_PTR(-EINVAL); >>>> } >>>> >>>> +void *bpf_map__data_area(const struct bpf_map *map, size_t *size) >>> >>> I'm not entirely thrilled about "data_area" name. This is entirely for >>> providing initial value for maps, so maybe something like >>> bpf_map__init_value() or something along those lines? >>> >>> Actually, how about a different API altogether: >>> >>> bpf_map__set_init_value(struct bpf_map *map, void *data, size_t size)? >>> >>> Application will have to prepare data of correct size, which will be >>> copied to libbpf's internal storage. It also doesn't expose any of >>> internal pointer. I don't think extra memcopy is a big deal here. >>> Thoughts? >> >> Huh, yeah, that's way better. Why didn't I think of that? Think maybe I >> was too focused on doing this the same way the skeleton code is. I'll >> send a v3 :) > > Could you please add a selftest as well? > I'm not excited about new features without tests. Sure, will do. -Toke
