On 3/12/24 7:00 AM, Quentin Monnet wrote:
2024-03-11 23:30 UTC+0000 ~ Yonghong Song <yonghong.song@xxxxxxxxx>
On 3/11/24 4:13 PM, Andrii Nakryiko wrote:
On Mon, Mar 11, 2024 at 2:41 PM Yonghong Song
<yonghong.song@xxxxxxxxx> 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.
[...]
