Re: [PATCH bpf-next 00/12] libbpf: Textual representation of enums

["Daniel Müller" <deso@posteo.net>]

On Mon, May 16, 2022 at 04:43:42PM -0700, Andrii Nakryiko wrote:
> On Mon, May 16, 2022 at 10:35 AM Daniel Müller <deso@posteo.net> wrote:
> >
> > This patch set introduces the means for querying a textual representation of
> > the following BPF related enum types:
> > - enum bpf_map_type
> > - enum bpf_prog_type
> > - enum bpf_attach_type
> > - enum bpf_link_type
> >
> > To make that possible, we introduce a new public function for each of the types:
> > libbpf_bpf_<type>_type_str.
> >
> > Having a way to query a textual representation has been asked for in the past
> > (by systemd, among others). Such representations can generally be useful in
> > tracing and logging contexts, among others. At this point, at least one client,
> > bpftool, maintains such a mapping manually, which is prone to get out of date as
> > new enum variants are introduced. libbpf is arguably best situated to keep this
> > list complete and up-to-date. This patch series adds BTF based tests to ensure
> > that exhaustiveness is upheld moving forward.
> >
> > The libbpf provided textual representation can be inferred from the
> > corresponding enum variant name by removing the prefix and lowercasing the
> > remainder. E.g., BPF_PROG_TYPE_SOCKET_FILTER -> socket_filter. Unfortunately,
> > bpftool does not use such a programmatic approach for some of the
> > bpf_attach_type variants. We propose a work around keeping the existing behavior
> > for the time being in the patch titled "bpftool: Use
> > libbpf_bpf_attach_type_str".
> >
> > The patch series is structured as follows:
> > - for each enumeration type in {bpf_prog_type, bpf_map_type, bpf_attach_type,
> >   bpf_link_type}:
> >   - we first introduce the corresponding public libbpf API function
> >   - we then add BTF based self-tests
> >   - we lastly adjust bpftool to use the libbpf provided functionality
> >
> > Signed-off-by: Daniel Müller <deso@posteo.net>
> >
> > Daniel Müller (12):
> >   libbpf: Introduce libbpf_bpf_prog_type_str
> >   selftests/bpf: Add test for libbpf_bpf_prog_type_str
> >   bpftool: Use libbpf_bpf_prog_type_str
> >   libbpf: Introduce libbpf_bpf_map_type_str
> >   selftests/bpf: Add test for libbpf_bpf_map_type_str
> >   bpftool: Use libbpf_bpf_map_type_str
> >   libbpf: Introduce libbpf_bpf_attach_type_str
> >   selftests/bpf: Add test for libbpf_bpf_attach_type_str
> >   bpftool: Use libbpf_bpf_attach_type_str
> >   libbpf: Introduce libbpf_bpf_link_type_str
> >   selftests/bpf: Add test for libbpf_bpf_link_type_str
> >   bpftool: Use libbpf_bpf_link_type_str
> >
> 
> Looks good to me overall. But keep in mind that libbpf v0.8 was just
> released, so these new APIs will have to go into 1.0 section in
> libbpf.map. It can't inherit from 0.8, btw, so this is a bit new
> procedure, I'll try to get to it in next few days. Meanwhile I'd like
> to get some feedback at least from Quentin on bpftool changes.

Thanks for the heads up (and the review)! I am happy to rebase once we have
figured out the procedure.

[...]

Daniel