> -----Original Message----- > From: Quentin Monnet <quentin@xxxxxxxxxxxxx> > Sent: Wednesday, May 18, 2022 6:32 AM > To: Daniel Müller <deso@xxxxxxxxxx> > Cc: Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>; bpf <bpf@xxxxxxxxxxxxxxx>; > Alexei Starovoitov <ast@xxxxxxxxxx>; Andrii Nakryiko <andrii@xxxxxxxxxx>; > Daniel Borkmann <daniel@xxxxxxxxxxxxx>; Kernel Team <kernel- > team@xxxxxx> > Subject: Re: [PATCH bpf-next 09/12] bpftool: Use libbpf_bpf_attach_type_str > > 2022-05-17 18:54 UTC+0000 ~ Daniel Müller <deso@xxxxxxxxxx> > > On Tue, May 17, 2022 at 03:18:41PM +0100, Quentin Monnet wrote: > >> 2022-05-16 16:41 UTC-0700 ~ Andrii Nakryiko > >> <andrii.nakryiko@xxxxxxxxx> > >>> 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? > >> Hi Andrii, Daniel, > > > > Hi Quentin, > > > >> Thanks for the ping! I'm unsure what's best, to be honest. Maybe we > >> should look at bpftool's inputs and outputs separately. > >> > >> For attach types printed as part of the output: > >> > >> Thinking about it, I'd say go for the libbpf API, and make the change > >> now. [...] I mentioned this at LSF/MM/BPF in the discussion of making bpftool & libbpf cross-platform, but yes it is a good direction (in terms of supporting more runtimes) to avoid as much as possible having per-prog/attach type info in bpftool itself. So yes depending on libbpf apis instead of hard coding in bpftool is good. Dave
