On Sat, 10 Jun 2023 at 03:22, Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > On Fri, Jun 9, 2023 at 12:36 PM Song Liu <song@xxxxxxxxxx> wrote: > > > > On Thu, Jun 8, 2023 at 4:14 PM Andrii Nakryiko > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > On Thu, Jun 8, 2023 at 3:35 AM Yafang Shao <laoar.shao@xxxxxxxxx> wrote: > > > > > > > > Add libbpf API to get generic perf event name. > > > > > > > > Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx> > > > > --- > > > > > > 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 > > > > 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. 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? Quentin
