Messages in this thread | | | Subject | Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality | From | Daniel Borkmann <> | Date | Wed, 27 Jun 2018 12:34:35 +0200 |
| |
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
| |