Re: [PATCH bpf-next 09/12] bpftool: Use libbpf_bpf_attach_type_str

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Mon, May 16, 2022 at 10:36 AM Daniel Müller <deso@posteo.net> wrote:
>
> 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 follow 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. In order to not brake compatibility (these textual
> representations appear in JSON and are used to parse user input), we
> introduce a program local bpf_attach_type_str that overrides the
> variants in question.
> We should consider removing this function and expect the libbpf string
> representation with the next backwards compatibility breaking release,
> if possible.
>
> Signed-off-by: Daniel Müller <deso@posteo.net>
> ---

Quentin, any opinion on this approach? Should we fallback to libbpf's
API for all the future cases or it's better to keep bpftool's own
attach_type mapping?

>  tools/bpf/bpftool/cgroup.c | 20 ++++++----
>  tools/bpf/bpftool/common.c | 82 +++++++++++++++++---------------------
>  tools/bpf/bpftool/link.c   | 15 ++++---
>  tools/bpf/bpftool/main.h   | 15 +++++++
>  4 files changed, 73 insertions(+), 59 deletions(-)
>

[...]