Re: [PATCH v2 bpf-next 09/11] libbpf: Add perf event names

From: Yafang Shao <laoar.shao@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>
Cc: Song Liu <song@kernel.org>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	ast@kernel.org,  daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, yhs@fb.com,  john.fastabend@gmail.com,
	kpsingh@kernel.org, sdf@google.com,  haoluo@google.com,
	jolsa@kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 09/11] libbpf: Add perf event names
Date: Sun, 11 Jun 2023 23:52:35 +0800	[thread overview]
Message-ID: <CALOAHbDBNhn1AR-HnnQpiQWrxD1B1FNZWbxizZwbXJGCRMwZXg@mail.gmail.com> (raw)
In-Reply-To: <CACdoK4L+pPFN=f6Q-KrZNVo5fwqxDBr51cuu_yz5W-GGumsmTQ@mail.gmail.com>

On Sun, Jun 11, 2023 at 4:35 AM Quentin Monnet <quentin@isovalent.com> wrote:
>
> On Sat, 10 Jun 2023 at 03:22, Yafang Shao <laoar.shao@gmail.com> wrote:
> >
> > On Fri, Jun 9, 2023 at 12:36 PM Song Liu <song@kernel.org> wrote:
> > >
> > > On Thu, Jun 8, 2023 at 4:14 PM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > >
> > > > On Thu, Jun 8, 2023 at 3:35 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> > > > >
> > > > > Add libbpf API to get generic perf event name.
> > > > >
> > > > > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > > > > ---
> > > >
> > > > I don't think this belongs in libbpf and shouldn't be exposed as
> > > > public API. Please move it into bpftool and make it internal (if
> > > > Quentin is fine with this in the first place).
>
> Fine by me

I will move them into bpftool.

>
> > >
> > > Or maybe it belongs to libperf?
> >
> > I prefer to move it into libperf.  Then it may be reused by other tools.
>
> Libperf sounds like a good place to have it, and I'm all in favour of
> having the names available to other tools, too.
>
> This being said, this would add a new dependency to bpftool. I'm not
> sure it's worth building libperf from bpftool's Makefile like we do
> for libbpf, just for getting the names: it would add to build time,
> and I don't see an easy way to replicate it on the GitHub mirror
> anyway. So the remaining option would be to use the library installed
> on the system if available, and to have a new feature detection in
> bpftool to figure out if the functions are available; but this also
> means most users compiling locally wouldn't get the names by default.

Agree with you that dependency is a problem.

>
> Looking at the list in the UAPI header, it seems to be relatively
> stable, so I'm fine with having it in bpftool, it shouldn't be too
> much overhead to keep up-to-date.
>
> Too bad these are enums and not macros in the UAPI, or we'd be able to
> derive the name without these arrays, given that it's just trimming
> the prefix and turning to lowercase. But maybe an alternative solution
> would be to get the name of the enum members with BTF, and derive the
> names from there? We already (optionally) rely on vmlinux.h at build
> time, maybe we can just reuse it?
>

As Jiri suggested, I think we can just put these code into bpftool,
and then try to improve it in the future.

-- 
Regards
Yafang