| Message ID | 20220516173540.3520665-1-deso@posteo.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | libbpf: Textual representation of enums | expand |
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. > tools/bpf/bpftool/cgroup.c | 20 +- > tools/bpf/bpftool/common.c | 46 ---- > tools/bpf/bpftool/feature.c | 87 +++++--- > tools/bpf/bpftool/link.c | 61 +++--- > tools/bpf/bpftool/main.h | 6 - > tools/bpf/bpftool/map.c | 82 +++---- > tools/bpf/bpftool/prog.c | 51 +---- > tools/lib/bpf/libbpf.c | 160 ++++++++++++++ > tools/lib/bpf/libbpf.h | 36 ++++ > tools/lib/bpf/libbpf.map | 4 + > .../selftests/bpf/prog_tests/libbpf_str.c | 201 ++++++++++++++++++ > 11 files changed, 539 insertions(+), 215 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/libbpf_str.c > > -- > 2.30.2 >
On 5/16/22 10:35 AM, Daniel Müller 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 > > tools/bpf/bpftool/cgroup.c | 20 +- > tools/bpf/bpftool/common.c | 46 ---- > tools/bpf/bpftool/feature.c | 87 +++++--- > tools/bpf/bpftool/link.c | 61 +++--- > tools/bpf/bpftool/main.h | 6 - > tools/bpf/bpftool/map.c | 82 +++---- > tools/bpf/bpftool/prog.c | 51 +---- > tools/lib/bpf/libbpf.c | 160 ++++++++++++++ > tools/lib/bpf/libbpf.h | 36 ++++ > tools/lib/bpf/libbpf.map | 4 + > .../selftests/bpf/prog_tests/libbpf_str.c | 201 ++++++++++++++++++ > 11 files changed, 539 insertions(+), 215 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/libbpf_str.c LGTM. Ack for the whole series. Acked-by: Yonghong Song <yhs@fb.com>
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
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 tools/bpf/bpftool/cgroup.c | 20 +- tools/bpf/bpftool/common.c | 46 ---- tools/bpf/bpftool/feature.c | 87 +++++--- tools/bpf/bpftool/link.c | 61 +++--- tools/bpf/bpftool/main.h | 6 - tools/bpf/bpftool/map.c | 82 +++---- tools/bpf/bpftool/prog.c | 51 +---- tools/lib/bpf/libbpf.c | 160 ++++++++++++++ tools/lib/bpf/libbpf.h | 36 ++++ tools/lib/bpf/libbpf.map | 4 + .../selftests/bpf/prog_tests/libbpf_str.c | 201 ++++++++++++++++++ 11 files changed, 539 insertions(+), 215 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/libbpf_str.c