Em Thu, Feb 14, 2019 at 10:11:56AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Thu, Feb 14, 2019 at 09:47:57AM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Feb 13, 2019 at 09:43:43PM -0800, Andrii Nakryiko escreveu: > > > happy with it. So consider this email a solicitation for naming > > > suggestion. Keep in mind, that all the pahole's functions of the form > > > btf__xxx will be renamed as well for consistency. If you like > > > btf_info, let me know as well, I'll just stick with it. > > > Can you try thinking if splitting this further into 'struct btf_loader', > > 'struct btf_encoder' that would live in the pahole sources and that > > refer to a 'struct btf' that lives in libbpf (or in libbtf, at some > > point) is a move that eases your current needs? > > So, the btf__new() in tools/lib/bpf/btf.c is basically a variant of > btf__new() in the pahole sources, probably we should go ahead and make > pahole use that btf__new() and do changes in tools/lib/bpf/btf.c to > allow for it to access internal state that it needs to do its job? No, we can't, because tools/lib/btf/btf.c btf__new() is centered on getting some BTF buffer no matter where it comes from and passing it to the kernel. So probably we should backtrack to my previous suggestion of having pahole use 'struct btf_loader', or even more explicitely, 'struct btf_elf' to make extra clear that this has nothing to do with the kernel, its purely about loading/encoding the BTF info from/to a ELF file. - Arnaldo
