aboutsummaryrefslogtreecommitdiff
path: root/tools/lib
diff options
context:
space:
mode:
authorDaniel Müller2022-05-23 23:04:25 +0000
committerAndrii Nakryiko2022-06-02 16:26:30 -0700
commit1ba5ad36e00f46e3f7676f5de6b87f5a2f57f1f1 (patch)
treee94a1aa6c059a535fbecae41fdc39f0a1c673a20 /tools/lib
parent0b27b3d9fdf88c132b095a30ee2c61cd6e56e6cc (diff)
bpftool: Use libbpf_bpf_attach_type_str
This change switches bpftool over to using the recently introduced libbpf_bpf_attach_type_str function instead of maintaining its own string representation for the bpf_attach_type enum. Note that contrary to other enum types, the variant names that bpftool maps bpf_attach_type to do not adhere a simple to follow rule. With bpf_prog_type, for example, the textual representation can easily be inferred by stripping the BPF_PROG_TYPE_ prefix and lowercasing the remaining string. bpf_attach_type violates this rule for various variants. We decided to fix up this deficiency with this change, meaning that bpftool uses the same textual representations as libbpf. Supporting tests, completion scripts, and man pages have been adjusted accordingly. However, we did add support for accepting (the now undocumented) original attach type names when they are provided by users. For the test (test_bpftool_synctypes.py), I have removed the enum representation checks, because we no longer mirror the various enum variant names in bpftool source code. For the man page, help text, and completion script checks we are now using enum definitions from uapi/linux/bpf.h as the source of truth directly. Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220523230428.3077108-10-deso@posteo.net
Diffstat (limited to 'tools/lib')
0 files changed, 0 insertions, 0 deletions