[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZUnk+qAyp86UW-w6MWYKYq+HqL5Q5e8SfKkna4pxFRcw@mail.gmail.com>
Date: Mon, 15 Apr 2019 17:54:04 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Yonghong Song <yhs@...com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Prashant Bhole <bhole_prashant_q7@....ntt.co.jp>,
Alexei Starovoitov <ast@...nel.org>,
Quentin Monnet <quentin.monnet@...ronome.com>,
Martin Lau <kafai@...com>, Song Liu <songliubraving@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Andrii Nakryiko <andriin@...com>
Subject: Re: [PATCH bpf-next] tools/bpftool: show btf id in program information
On Thu, Apr 11, 2019 at 8:38 AM Yonghong Song <yhs@...com> wrote:
>
>
> cc Andrii
>
> On 4/11/19 12:51 AM, Daniel Borkmann wrote:
> > On 04/10/2019 05:39 PM, Jakub Kicinski wrote:
> >> On Wed, 10 Apr 2019 13:56:42 +0900, Prashant Bhole wrote:
> >>> Let's add a way to know whether a program has btf context.
> >>> Patch adds 'btf_id' in the output of program listing.
> >>> When btf_id is present, it means program has btf context.
> >>>
> >>> Sample output:
> >>> user@...t# bpftool prog list
> >>> 25: xdp name xdp_prog1 tag 539ec6ce11b52f98 gpl
> >>> loaded_at 2019-04-10T11:44:20+0900 uid 0
> >>> xlated 488B not jited memlock 4096B map_ids 23
> >>> btf_id 1
> >>>
> >>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@....ntt.co.jp>
> >>
> >> Acked-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
> >
> > Applied, thanks!
> >
> > What would be the plan for the maps listing?
> [...]
> > I think what we could also potentially have is some way to dump
> > the BTF type info based on such above id. Perhaps it would make
> > sense to similarly share the verifier's printer with bpftool?
>
> Agreed. It does make sense to print the detailed info for a btf id
> through bpftool.
>
> Andrii had a btf dumper to dump types as well as BTF elf file .btf.ext
> contents in his private branch. Maybe Andrii can comment further
> on this subject.
Yes, absolutely, we should have this as part of bpftool. I'm going to
start porting this logic from my private prototype very soon.
I think we should be able to have both low-level (though still
human-readable) BTF dump as close to underlying BTF data as possible,
as well as an ability to dump struct/union/datasec definitions in
compilable C format. E.g., for struct/union it will be struct/union
definition, as well as all the necessary dependent types, for
datasec/vars it will be a list of global variables declaration w/ all
the necessary types. Thoughts?
Powered by blists - more mailing lists