bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf@google.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: "Alexei Starovoitov" <ast@fb.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	bpf <bpf@vger.kernel.org>, "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Kernel Team" <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 09/10] libbpf: simplify look up by name of internal maps
Date: Wed, 20 Oct 2021 11:09:19 -0700	[thread overview]
Message-ID: <CAKH8qBsazaRM+ACSJc69Tt9RXR95twtG-T+Sn8LmV9sKWkhu1Q@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzYkrabS=7fpn01BesM06P9gNEreQLReQBhbbqhvW6dTzQ@mail.gmail.com>

On Wed, Oct 20, 2021 at 10:59 AM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Oct 12, 2021 at 8:29 AM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > 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.
>
> Well, maps have associated BTF fd, when they are created, no? So you
> can find all the same metadata for the map, no?

I guess that's true, we can store this metadata in the map itself
using something like existing bpf_metadata_ prefix.

  reply	other threads:[~2021-10-20 18:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08  0:02 [PATCH bpf-next 00/10] libbpf: support custom .rodata.*/.data.* sections andrii.nakryiko
2021-10-08  0:03 ` [PATCH bpf-next 01/10] libbpf: deprecate btf__finalize_data() and move it into libbpf.c andrii.nakryiko
2021-10-08  6:06   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 02/10] libbpf: extract ELF processing state into separate struct andrii.nakryiko
2021-10-08  6:06   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 03/10] libbpf: use Elf64-specific types explicitly for dealing with ELF andrii.nakryiko
2021-10-08  6:10   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 04/10] libbpf: remove assumptions about uniqueness of .rodata/.data/.bss maps andrii.nakryiko
2021-10-08  6:05   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 05/10] bpftool: support multiple .rodata/.data internal maps in skeleton andrii.nakryiko
2021-10-08  6:05   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 06/10] bpftool: improve skeleton generation for data maps without DATASEC type andrii.nakryiko
2021-10-08 17:15   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 07/10] libbpf: support multiple .rodata.* and .data.* BPF maps andrii.nakryiko
2021-10-08 22:05   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 08/10] selftests/bpf: demonstrate use of custom .rodata/.data sections andrii.nakryiko
2021-10-08 22:07   ` Song Liu
2021-10-11 13:57   ` Daniel Borkmann
2021-10-12  3:47     ` Andrii Nakryiko
2021-10-12 14:54       ` Daniel Borkmann
2021-10-20 19:02         ` Andrii Nakryiko
2021-10-08  0:03 ` [PATCH bpf-next 09/10] libbpf: simplify look up by name of internal maps andrii.nakryiko
2021-10-08 17:30   ` Toke Høiland-Jørgensen
2021-10-08 18:21     ` Andrii Nakryiko
2021-10-08 21:44       ` Toke Høiland-Jørgensen
2021-10-11 21:24         ` Alexei Starovoitov
2021-10-12  3:45           ` Andrii Nakryiko
2021-10-12 15:29             ` Stanislav Fomichev
2021-10-20 17:59               ` Andrii Nakryiko
2021-10-20 18:09                 ` Stanislav Fomichev [this message]
2021-10-20 18:20                   ` Andrii Nakryiko
2021-10-20 22:03                     ` Toke Høiland-Jørgensen
2021-10-20 22:24                       ` Stanislav Fomichev
2021-10-20 22:25                       ` Andrii Nakryiko
2021-10-21 11:39                         ` Toke Høiland-Jørgensen
2021-10-08 22:16   ` Song Liu
2021-10-08  0:03 ` [PATCH bpf-next 10/10] selftests/bpf: switch to ".bss"/".rodata"/".data" lookups for " andrii.nakryiko
2021-10-08 22:16   ` Song Liu
2021-10-11 21:30 ` [PATCH bpf-next 00/10] libbpf: support custom .rodata.*/.data.* sections Alexei Starovoitov
2021-10-12  3:36   ` Andrii Nakryiko
2021-10-12  4:15 ` Kumar Kartikeya Dwivedi
2021-10-21  0:14   ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKH8qBsazaRM+ACSJc69Tt9RXR95twtG-T+Sn8LmV9sKWkhu1Q@mail.gmail.com \
    --to=sdf@google.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=toke@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).