On Mon, Oct 11, 2021 at 11:24 PM Alexei Starovoitov <ast@xxxxxx> 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.
