On Tue, Sep 29, 2020 at 05:44:48PM -0700, Andrii Nakryiko wrote: > On Tue, Sep 29, 2020 at 5:03 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Tue, Sep 29, 2020 at 04:28:39PM -0700, Andrii Nakryiko wrote: > > > Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF type > > > information, same as bpftool output. bpftool is not switched to this API > > > because bpftool still needs to perform all the same BTF type processing logic > > > to do JSON output, so benefits are pretty much zero. > > > > If the only existing user cannot actually use such api it speaks heavily > > against adding such api to libbpf. Comparing strings in tests is nice, but > > could be done with C output just as well. > > It certainly can, it just won't save much code, because bpftool would > still need to have a big switch over BTF type kinds to do JSON output. So you're saying that most of the dump_btf_type() in bpftool/btf.c will stay as-is. Only 'if (json_output)' will become unconditional? Hmm. I know you don't want json in libbpf, but I think it's the point of making a call on such things. Either libbpf gets to dump both json and text dump_btf_type()-like output or it stays with C only. Doing C and this text and not doing json is inconsistent. Either libbpf can print btf in many different ways or it stays with C. 2nd format is not special in any way. I don't think that text and json formats bring much value comparing to C, so I would be fine with C only. But if we allow 2nd format we should do json at the same time too to save bpftool the hassle. And in the future we should allow 4th and 5th formats.
