Re: [PATCH bpf-next] bpftool: Fix missing pids during link show

[Yonghong Song <yonghong.song@linux.dev>]

On 3/12/24 7:00 AM, Quentin Monnet wrote:
> 2024-03-11 23:30 UTC+0000 ~ Yonghong Song <yonghong.song@linux.dev>
>> On 3/11/24 4:13 PM, Andrii Nakryiko wrote:
>>> On Mon, Mar 11, 2024 at 2:41 PM Yonghong Song
>>> <yonghong.song@linux.dev> wrote:
>>>> Current 'bpftool link' command does not show pids, e.g.,
>>>>     $ tools/build/bpftool/bpftool link
>>>>     ...
>>>>     4: tracing  prog 23
>>>>           prog_type lsm  attach_type lsm_mac
>>>>           target_obj_id 1  target_btf_id 31320
>>>>
>>>> Hack the following change to enable normal libbpf debug output,
>>>>     --- a/tools/bpf/bpftool/pids.c
>>>>     +++ b/tools/bpf/bpftool/pids.c
>>>>     @@ -121,9 +121,9 @@ int build_obj_refs_table(struct hashmap **map,
>>>> enum bpf_obj_type type)
>>>>             /* we don't want output polluted with libbpf errors if
>>>> bpf_iter is not
>>>>              * supported
>>>>              */
>>>>     -       default_print = libbpf_set_print(libbpf_print_none);
>>>>     +       /* default_print = libbpf_set_print(libbpf_print_none); */
>>>>             err = pid_iter_bpf__load(skel);
>>>>     -       libbpf_set_print(default_print);
>>>>     +       /* libbpf_set_print(default_print); */
> I'm taking note to make these logs available when users pass the --debug
> flag (https://github.com/libbpf/bpftool/issues/137), there's no reason
> to hide them in that case.

Totally make sense as most kernels used in production should already have
bpf_link and bpf_iter support already.

[...]