On Mon, May 16, 2022 at 10:36 AM Daniel Müller <deso@xxxxxxxxxx> 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@xxxxxxxxxx> > --- 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(-) > [...]
