Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality

[Daniel Borkmann]

On 06/27/2018 12:35 AM, Jakub Kicinski wrote:
> On Tue, 26 Jun 2018 15:27:09 -0700, Martin KaFai Lau wrote:
>> On Tue, Jun 26, 2018 at 01:31:33PM -0700, Jakub Kicinski wrote:
[...]
>>> Implementing both outputs in one series will help you structure your
>>> code to best suit both of the formats up front.  
>> hex and "formatted" are the only things missing?  As always, things
>> can be refactored when new use case comes up.  Lets wait for
>> Okash input.
>>
>> Regardless, plaintext is our current use case.  Having the current
>> patchset in does not stop us or others from contributing other use
>> cases (json, "bpftool map find"...etc),  and IMO it is actually
>> the opposite.  Others may help us get there faster than us alone.
>> We should not stop making forward progress and take this patch
>> as hostage because "abc" and "xyz" are not done together.
> 
> Parity between JSON and plain text output is non negotiable.

Longish discussion and some confusion in this thread. :-) First of all
thanks a lot for working on it, very useful! My $0.02 on it is that so far
great care has been taken in bpftool to indeed have feature parity between
JSON and plain text, so it would be highly desirable to keep continuing
this practice if the consensus is that it indeed is feasible and makes
sense wrt BTF data. There has been mentioned that given BTF data can be
dynamic depending on what the user loads via bpf(2) so a potential JSON
output may look different/break each time anyway. This however could all be
embedded under a container object that has a fixed key like 'formatted'
where tools like jq(1) can query into it. I think this would be fine since
the rest of the (non-dynamic) output is still retained as-is and then
wouldn't confuse or collide with existing users, and anyone programmatically
parsing deeper into the BTF data under such JSON container object needs
to have awareness of what specific data it wants to query from it; so
there's no conflict wrt breaking anything here. Imho, both outputs would
be very valuable.

Thanks,
Daniel