From mboxrd@z Thu Jan 1 00:00:00 1970 From: Okash Khawaja Subject: Re: [PATCH bpf-next 2/3] bpf: btf: add btf json print functionality Date: Wed, 27 Jun 2018 12:47:39 +0100 Message-ID: <20180627114737.GA1580@w1t1fb> References: <20180622205535.c6vjhdwt5er4wc32@kafai-mbp.dhcp.thefacebook.com> <20180622142743.2b890d0f@cakuba.netronome.com> <20180622225408.jor7lpvsksnwiiec@kafai-mbp.dhcp.thefacebook.com> <20180622163200.20564ec4@cakuba.netronome.com> <20180623002639.h4qxy7aakypi6t7b@kafai-mbp.dhcp.thefacebook.com> <20180626164820.GA12981@w1t1fb> <20180626133133.618af1d3@cakuba.netronome.com> <20180626222709.fsznwqauxojhhx7v@kafai-mbp.dhcp.thefacebook.com> <20180626153559.0511f709@cakuba.netronome.com> <23968d53-2895-f0bc-a38c-5bc99e1846ab@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Jakub Kicinski , Martin KaFai Lau , Alexei Starovoitov , Yonghong Song , Quentin Monnet , "David S. Miller" , , , To: Daniel Borkmann Return-path: Content-Disposition: inline In-Reply-To: <23968d53-2895-f0bc-a38c-5bc99e1846ab@iogearbox.net> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, Jun 27, 2018 at 12:34:35PM +0200, Daniel Borkmann wrote: > 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! Thanks :) > 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. Okay I can add "formatted" object under json output. One thing to note here is that the fixed output will change if the map itself changes. So someone writing a program that consumes that fixed output will have to account for his program breaking in future, thus breaking backward compatibility anyway as far as the developer is concerned :) I will go ahead with work on "formatted" object. Thanks, Okash > > Thanks, > Daniel