On Sun, Jun 11, 2023 at 4:35 AM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote: > > 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 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
