Re: pahole: soliciting naming suggestion for struct btf rename

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Wed, Feb 13, 2019 at 09:43:43PM -0800, Andrii Nakryiko escreveu:
> Hi folks,
> 
> I'm working on adding btf__dedup() support to pahole when doing DWARF
> to BTF conversion, which requires usage of libbpf from pahole. I've
> already added libbpf as a submodule and pahole now reuses btf.h header
> with all the btf struct definitions. Next step is actually using
> btf__dedup().
> 
> The problem with that is that both libbpf and pahole define their own
> incompatible versions of struct btf, which causes a lot of naming
> conflicts when I'm trying to use libbpf along those structs. Pahole
> has it's own internal library centered around struct btf with lots of
> useful methods to manipulate BTF data. My intent is to migrate most of
> that functionality (e.g., pretty-printing and BTF types construction)
> into libbpf, so maybe in the future pahole won't need it's own struct
> btf, but for now I'd like to avoid blocking on that.

I wonder if we should have a libbtf, with the same licensing as libbpf,
as, for instance, pahole would be interested only in the btf parts, be
it encoding, loading and pretty printing.

In fact the pretty printing part perhaps could be done exclusively using
the BTF parts, with the dwarf loader just being the current BTF encoder,
if we manage to not lose any information from DWARF, which is the case
for example, for multi dimensional arrays.

Having tools/lib/btf/ in the kernel sources would be nice for that, in
the long run I could even make a leaner pahole in tools/pahole/,
starting with the basic BTF pretty printing and in time getting the
other features, like struct reorganization to eliminate holes, etc, that
could, in time, even be something interesting to use in more situations.
 
> So to make progress I'll need to rename pahole's struct btf into
> something else. And I've been struggling to come up with good succinct
> name. The best I've got so far is btf_info, but I can't say I'm too

Humm, I think that what is being left for pahole is the encoding part,
right? So perhaps rename it to btf_encoder, the btf_loader part can use
libbpf's btf struct?

> 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?

- Arnaldo