On Thu, May 13, 2021 at 3:22 PM Alexei Starovoitov <ast@xxxxxx> wrote: > > On 5/13/21 2:16 PM, Andrii Nakryiko wrote: > > On Wed, May 12, 2021 at 2:33 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > >> > >> From: Alexei Starovoitov <ast@xxxxxxxxxx> > >> > >> Introduce bpf_map__initial_value() to read initial contents > >> of rodata/bss maps. Note only mmaped maps qualify. > >> Just as bpf_map__set_initial_value() works only for mmaped kconfig. > > > > This sentence is confusing. bpf_map__set_initial_value() rejects > > LIBBPF_MAP_KCONFIG, so it *doesn't* work for kconfig. But your > > implementation will return non-NULL pointer for kconfig (it will be > > all zeroes before load). So did you intend to match > > set_initial_value() semantics or not? > > Good catch. I'll reword. > It was too forward looking and ended up as completely incorrect > sentence. > > The idea was to make getter work for all is_internal and mmaped > maps (including kconfig), so that after __open and before __load > phase can populate them with correct values. > Initially for kconfig I was thinking to do it as part of the loader > program, but the kernel doesn't have in memory kconfig. Unzipping > and string searching didn't feel like the right task for > the loader prog/kernel, so the light skel instead will populate > it from user space during __open. > At that point we can either fail the __open if /proc/config.gz > cannot be open or it doesn't have the fields the prog is looking for > or proceed with default values in kconfig map that libbpf populated > earlier during light skel and loader prog generation. > Depending on that choice the bpf_map__initial_value() should > either return initial value for kconfig or not. > I think returning it for kconfig map doesn't hurt. Yep, I agree.
