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: Fri, 22 Jun 2018 23:48:12 +0100 Message-ID: <20180622224811.GA2566@w1t1fb> References: <20180620203703.101156292@fb.com> <20180621145935.41ff8974@cakuba.netronome.com> <20180621225117.dhrkrtmkfbeihbe4@kafai-mbp.dhcp.thefacebook.com> <20180621160719.2cfb4b58@cakuba.netronome.com> <20180621235746.dfq6kdtkogftw3ws@kafai-mbp.dhcp.thefacebook.com> <20180621172523.6cd00ed1@cakuba.netronome.com> <20180622012052.htkvholi674x6i4f@kafai-mbp.dhcp.thefacebook.com> <20180622114032.162b2a76@cakuba.netronome.com> <20180622205535.c6vjhdwt5er4wc32@kafai-mbp.dhcp.thefacebook.com> <20180622142743.2b890d0f@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Martin KaFai Lau , Daniel Borkmann , Alexei Starovoitov , Yonghong Song , Quentin Monnet , "David S. Miller" , , , To: Jakub Kicinski Return-path: Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:53376 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754559AbeFVWs7 (ORCPT ); Fri, 22 Jun 2018 18:48:59 -0400 Content-Disposition: inline In-Reply-To: <20180622142743.2b890d0f@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, Jun 22, 2018 at 02:27:43PM -0700, Jakub Kicinski wrote: [...] > > > should just use the BTF, I'm not sure we should format indexes for > > > arrays nicely or not :S > > > > > > > The key could also be a struct (e.g. a struct to describe ip:port). > > > > Can you suggest how the "key_struct" will look like? > > > > > > Hm. I think in my mind it has only been a struct but that's not true :S > > > So the struct in the name makes very limited sense now. > > > > > > Should we do: > > > "formatted" : { > > > "value" : XXX > > > } > > > > > > Where > > > XXX == plain int for integers, e.g. "value":0 > > > XXX == array for arrays, e.g. "value":[1,2,3,4] > > > XXX == object for objects, e.g. "value":{"field":XXX, "field2":XXX} > > It is exactly how this patch is using json's {}, [] and int. ;) > > Great, then just wrap that in a "formatted" object instead of > redefining fields and we're good? Please don't let two formats of same data in a single ouput. Overloading same output with multple formats suggests a confused design, IMO. It will confuse users too. > > > but other than that, it does not have to be json. > > In the next spin, lets stop calling this output json to avoid wrong > > user's expection and I also don't want the future readability > > improvements to be limited by that. Lets call it something > > like plain text output with BTF. > > I don't understand. We are discussing JSON output here. The example we > are commenting on is output of: > > $ sudo bpftool map dump -p id 14 > > That -p means JSON. Nobody objects to plain test output changes. I > actually didn't realize you haven't implemented plain text in this > series, we should have both. > > > How about: > > When "bpftool map dump id 1" is used, it will print the BTF plaintext output > > if a map has BTF available. If not, it will print the existing > > plaintext output. That should solve the concern about the user may not > > know BTF is available. > > > > This ascii output is for human. The script should not parse the ascii output > > because it is silly not to use the binary ABI (like what this patch is using) > > which does not suffer backward compat issue. > > What binary ABI? Reading binary data and linking it with BTF information. > I'm also not 100% sure what this patch is doing as it > adds bunch of code in new files that never gets called: Please take a look at the patch then :) Code in these files does get called. We seem to be conflating two different - and conflicting - intents here. First is progam-readability of the output and second is human readability of the output. I believe both are important. Let's leave existing output for programs to read. That way we can try to keep it backward compatible as well as JSON compatible. Let's dedicate the new BTF format for humans to read. That way, we don't have to worry about backward compatibility or JSON compatibility. Let me know if this is not clear. If we agree on above then I think we can move towards a solution. Thanks, Okash