Re: [PATCH bpf-next 2/2] bpftool: Show target_{obj,btf}_id in tracing link info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 16, 2023 at 9:19 PM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
>
> 2023-05-16 21:09 UTC+0800 ~ Yafang Shao <laoar.shao@xxxxxxxxx>
> > On Tue, May 16, 2023 at 9:01 PM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
> >>
> >> 2023-05-16 12:39 UTC+0000 ~ Yafang Shao <laoar.shao@xxxxxxxxx>
> >>> The target_btf_id can help us understand which kernel function is
> >>> linked by a tracing prog. The target_btf_id and target_obj_id have
> >>> already been exposed to userspace, so we just need to show them.
> >>>
> >>> The result as follows,
> >>>
> >>> $ tools/bpf/bpftool/bpftool link show
> >>> 2: tracing  prog 13
> >>>         prog_type tracing  attach_type trace_fentry
> >>>         target_obj_id 1  target_btf_id 13964
> >>>         pids trace(10673)
> >>>
> >>> $ tools/bpf/bpftool/bpftool link show -j
> >>> [{"id":2,"type":"tracing","prog_id":13,"prog_type":"tracing","attach_type":"trace_fentry","target_obj_id":1,"target_btf_id":13964,"pids":[{"pid":10673,"comm":"trace"}]}]
> >>>
> >>> Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx>
> >>> Acked-by: Song Liu <song@xxxxxxxxxx>
> >>> ---
> >>>  tools/bpf/bpftool/link.c | 4 ++++
> >>>  1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
> >>> index 243b74e..cfe896f 100644
> >>> --- a/tools/bpf/bpftool/link.c
> >>> +++ b/tools/bpf/bpftool/link.c
> >>> @@ -195,6 +195,8 @@ static int show_link_close_json(int fd, struct bpf_link_info *info)
> >>>
> >>>               show_link_attach_type_json(info->tracing.attach_type,
> >>>                                          json_wtr);
> >>> +             jsonw_uint_field(json_wtr, "target_obj_id", info->tracing.target_obj_id);
> >>> +             jsonw_uint_field(json_wtr, "target_btf_id", info->tracing.target_btf_id);
> >>>               break;
> >>>       case BPF_LINK_TYPE_CGROUP:
> >>>               jsonw_lluint_field(json_wtr, "cgroup_id",
> >>> @@ -375,6 +377,8 @@ static int show_link_close_plain(int fd, struct bpf_link_info *info)
> >>>                       printf("\n\tprog_type %u  ", prog_info.type);
> >>>
> >>>               show_link_attach_type_plain(info->tracing.attach_type);
> >>> +             printf("\n\ttarget_obj_id %u  target_btf_id %u  ",
> >>> +                        info->tracing.target_obj_id, info->tracing.target_btf_id);
> >>
> >> Older kernels won't share this info, so maybe we can skip this printf()
> >> in plain output if the target object and BTF ids are 0?
> >>
> >
> > Good suggestion. Will change it in the next version.
> > BTW, shouldn't we skip it in the json output as well ?
>
> I'd keep it in JSON. Plain output is for reading in the console, we want
> to make it easy for users to find the relevant info. JSON is for machine
> consumption, it's OK to be more exhaustive and to leave it to the
> consuming program to decide what's relevant and what's not.
>

Got it. Thanks for the explanation.


-- 
Regards
Yafang





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux