Re: [PATCH bpf-next 09/10] libbpf: simplify look up by name of internal maps

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Mon, Oct 11, 2021 at 11:24 PM Alexei Starovoitov <ast@fb.com> wrote:
>
> On 10/8/21 2:44 PM, Toke Høiland-Jørgensen wrote:
> >
> > Hmm, so introduce a new 'map_name_long' field, and on query the kernel
> > will fill in the old map_name with a truncated version, and put the full
> > name in the new field? Yeah, I guess that would work too!
>
> Let's start storing full map names in BTF instead.
> Like we do already for progs.
> Some tools already fetch full prog names this way.

We do have those names in BTF. Each map has either corresponding VAR
or DATASEC. The problem is that we don't know which.

Are you proposing to add some extra "btf_def_type_id" field to specify
BTF type ID of what "defines" the map (VAR or DATASEC)? That would
work. Would still require UAPI and kernel changes, of course.

The reason Toke and others were asking to preserve that object name
prefix for .rodata/.data maps was different though, and won't be
addressed by the above. Even if you know the BTF VAR/DATASEC, you
don't know the "object name" associated with the map. And the kernel
doesn't know because it's purely libbpf's abstraction. And sometimes
that abstraction doesn't make sense (e.g., if we create a map that's
pinned and reused from multiple BPF apps/objects).

We do have BPF metadata that Stanislav added a while ago, so maybe we
should just punt that problem to that? I'd love to have clean
".rodata" and ".data" names, of course.