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

[Stanislav Fomichev <sdf@google.com>]

On Mon, Oct 11, 2021 at 8:45 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> 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.

Are you suggesting we add some option to associate the metadata with
the maps (might be an option)? IIRC, the metadata can only be
associated with the progs right now.