diff mbox series

[bpf-next,v3,3/4] bpftool: btf: Support dumping a single type from file

Message ID 3bc17d33161961409dc77a5de29761bf2bed4980.1733787798.git.dxu@dxuuu.xyz (mailing list archive)
State Superseded
Delegated to: BPF
Headers show
Series bpftool: btf: Support dumping a single type from file | expand

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Clearly marked for bpf-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/build_tools success Errors and warnings before: 0 (+0) this patch: 0 (+0)
netdev/cc_maintainers warning 1 maintainers not CCed: rameezrehman408@hotmail.com
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 58 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-10 success Logs for aarch64-gcc / veristat-kernel
bpf/vmtest-bpf-next-VM_Test-11 success Logs for aarch64-gcc / veristat-meta
bpf/vmtest-bpf-next-VM_Test-13 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-17 success Logs for s390x-gcc / veristat-kernel
bpf/vmtest-bpf-next-VM_Test-18 success Logs for s390x-gcc / veristat-meta
bpf/vmtest-bpf-next-VM_Test-19 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-17 / veristat-kernel
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-17 / veristat-meta
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-next-VM_Test-45 success Logs for x86_64-llvm-18 / veristat-kernel
bpf/vmtest-bpf-next-VM_Test-46 success Logs for x86_64-llvm-18 / veristat-meta
bpf/vmtest-bpf-next-VM_Test-15 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-gcc / veristat-kernel / x86_64-gcc veristat_kernel
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-gcc / veristat-meta / x86_64-gcc veristat_meta
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-42 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-43 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-44 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc

Commit Message

Daniel Xu Dec. 9, 2024, 11:44 p.m. UTC 
Some projects, for example xdp-tools [0], prefer to check in a minimized
vmlinux.h rather than the complete file which can get rather large.

However, when you try to add a minimized version of a complex struct (eg
struct xfrm_state), things can get quite complex if you're trying to
manually untangle and deduplicate the dependencies.

This commit teaches bpftool to do a minimized dump of a single type by
providing an optional root_id argument.

Example usage:

    $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
    [12643] STRUCT 'xfrm_state' size=912 vlen=58

    $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
    #ifndef __VMLINUX_H__
    #define __VMLINUX_H__

    [..]

    struct xfrm_type_offload;

    struct xfrm_sec_ctx;

    struct xfrm_state {
            possible_net_t xs_net;
            union {
                    struct hlist_node gclist;
                    struct hlist_node bydst;
            };
            union {
                    struct hlist_node dev_gclist;
                    struct hlist_node bysrc;
            };
            struct hlist_node byspi;
    [..]

[0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
---
 .../bpf/bpftool/Documentation/bpftool-btf.rst |  7 +++++--
 tools/bpf/bpftool/btf.c                       | 21 ++++++++++++++++++-
 2 files changed, 25 insertions(+), 3 deletions(-)

Comments

Andrii Nakryiko Dec. 12, 2024, 7:09 p.m. UTC | #1 
On Mon, Dec 9, 2024 at 3:45 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> Some projects, for example xdp-tools [0], prefer to check in a minimized
> vmlinux.h rather than the complete file which can get rather large.
>
> However, when you try to add a minimized version of a complex struct (eg
> struct xfrm_state), things can get quite complex if you're trying to
> manually untangle and deduplicate the dependencies.
>
> This commit teaches bpftool to do a minimized dump of a single type by
> providing an optional root_id argument.
>
> Example usage:
>
>     $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
>     [12643] STRUCT 'xfrm_state' size=912 vlen=58
>
>     $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
>     #ifndef __VMLINUX_H__
>     #define __VMLINUX_H__
>
>     [..]
>
>     struct xfrm_type_offload;
>
>     struct xfrm_sec_ctx;
>
>     struct xfrm_state {
>             possible_net_t xs_net;
>             union {
>                     struct hlist_node gclist;
>                     struct hlist_node bydst;
>             };
>             union {
>                     struct hlist_node dev_gclist;
>                     struct hlist_node bysrc;
>             };
>             struct hlist_node byspi;
>     [..]
>
> [0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h
>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
>  .../bpf/bpftool/Documentation/bpftool-btf.rst |  7 +++++--
>  tools/bpf/bpftool/btf.c                       | 21 ++++++++++++++++++-
>  2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> index 245569f43035..4899b2c10777 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> @@ -24,7 +24,7 @@ BTF COMMANDS
>  =============
>
>  | **bpftool** **btf** { **show** | **list** } [**id** *BTF_ID*]
> -| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*]
> +| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*] [**root_id** *ROOT_ID*]
>  | **bpftool** **btf help**
>  |
>  | *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
> @@ -43,7 +43,7 @@ bpftool btf { show | list } [id *BTF_ID*]
>      that hold open file descriptors (FDs) against BTF objects. On such kernels
>      bpftool will automatically emit this information as well.
>
> -bpftool btf dump *BTF_SRC* [format *FORMAT*]
> +bpftool btf dump *BTF_SRC* [format *FORMAT*] [root_id *ROOT_ID*]
>      Dump BTF entries from a given *BTF_SRC*.
>
>      When **id** is specified, BTF object with that ID will be loaded and all
> @@ -67,6 +67,9 @@ bpftool btf dump *BTF_SRC* [format *FORMAT*]
>      formatting, the output is sorted by default. Use the **unsorted** option
>      to avoid sorting the output.
>
> +    **root_id** option can be used to filter a dump to a single type and all
> +    its dependent types. It cannot be used with any other types of filtering.
> +
>  bpftool btf help
>      Print short help message.
>
> diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> index 3e995faf9efa..18b037a1414b 100644
> --- a/tools/bpf/bpftool/btf.c
> +++ b/tools/bpf/bpftool/btf.c
> @@ -993,6 +993,25 @@ static int do_dump(int argc, char **argv)
>                                 goto done;
>                         }
>                         NEXT_ARG();
> +               } else if (is_prefix(*argv, "root_id")) {
> +                       __u32 root_id;
> +                       char *end;
> +
> +                       if (root_type_cnt) {
> +                               p_err("cannot use root_id with other type filtering");

this is a confusing error if the user just wanted to provide two
root_id arguments... Also, why don't we allow multiple root_ids?

I'd bump root_type_ids[] to have something like 16 elements or
something (though we can always do dynamic realloc as well, probably),
and allow multiple types to be specified.

Thoughts?


> +                               err = -EINVAL;
> +                               goto done;
> +                       }
> +
> +                       NEXT_ARG();
> +                       root_id = strtoul(*argv, &end, 0);
> +                       if (*end) {
> +                               err = -1;
> +                               p_err("can't parse %s as root ID", *argv);
> +                               goto done;
> +                       }
> +                       root_type_ids[root_type_cnt++] = root_id;
> +                       NEXT_ARG();
>                 } else if (is_prefix(*argv, "unsorted")) {
>                         sort_dump_c = false;
>                         NEXT_ARG();
> @@ -1403,7 +1422,7 @@ static int do_help(int argc, char **argv)
>
>         fprintf(stderr,
>                 "Usage: %1$s %2$s { show | list } [id BTF_ID]\n"
> -               "       %1$s %2$s dump BTF_SRC [format FORMAT]\n"
> +               "       %1$s %2$s dump BTF_SRC [format FORMAT] [root_id ROOT_ID]\n"
>                 "       %1$s %2$s help\n"
>                 "\n"
>                 "       BTF_SRC := { id BTF_ID | prog PROG | map MAP [{key | value | kv | all}] | file FILE }\n"
> --
> 2.46.0
>
Daniel Xu Dec. 12, 2024, 11:41 p.m. UTC | #2 
On Thu, Dec 12, 2024 at 11:09:34AM GMT, Andrii Nakryiko wrote:
> On Mon, Dec 9, 2024 at 3:45 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
> >
> > Some projects, for example xdp-tools [0], prefer to check in a minimized
> > vmlinux.h rather than the complete file which can get rather large.
> >
> > However, when you try to add a minimized version of a complex struct (eg
> > struct xfrm_state), things can get quite complex if you're trying to
> > manually untangle and deduplicate the dependencies.
> >
> > This commit teaches bpftool to do a minimized dump of a single type by
> > providing an optional root_id argument.
> >
> > Example usage:
> >
> >     $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
> >     [12643] STRUCT 'xfrm_state' size=912 vlen=58
> >
> >     $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
> >     #ifndef __VMLINUX_H__
> >     #define __VMLINUX_H__
> >
> >     [..]
> >
> >     struct xfrm_type_offload;
> >
> >     struct xfrm_sec_ctx;
> >
> >     struct xfrm_state {
> >             possible_net_t xs_net;
> >             union {
> >                     struct hlist_node gclist;
> >                     struct hlist_node bydst;
> >             };
> >             union {
> >                     struct hlist_node dev_gclist;
> >                     struct hlist_node bysrc;
> >             };
> >             struct hlist_node byspi;
> >     [..]
> >
> > [0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h
> >
> > Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> > ---
> >  .../bpf/bpftool/Documentation/bpftool-btf.rst |  7 +++++--
> >  tools/bpf/bpftool/btf.c                       | 21 ++++++++++++++++++-
> >  2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > index 245569f43035..4899b2c10777 100644
> > --- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > @@ -24,7 +24,7 @@ BTF COMMANDS
> >  =============
> >
> >  | **bpftool** **btf** { **show** | **list** } [**id** *BTF_ID*]
> > -| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*]
> > +| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*] [**root_id** *ROOT_ID*]
> >  | **bpftool** **btf help**
> >  |
> >  | *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
> > @@ -43,7 +43,7 @@ bpftool btf { show | list } [id *BTF_ID*]
> >      that hold open file descriptors (FDs) against BTF objects. On such kernels
> >      bpftool will automatically emit this information as well.
> >
> > -bpftool btf dump *BTF_SRC* [format *FORMAT*]
> > +bpftool btf dump *BTF_SRC* [format *FORMAT*] [root_id *ROOT_ID*]
> >      Dump BTF entries from a given *BTF_SRC*.
> >
> >      When **id** is specified, BTF object with that ID will be loaded and all
> > @@ -67,6 +67,9 @@ bpftool btf dump *BTF_SRC* [format *FORMAT*]
> >      formatting, the output is sorted by default. Use the **unsorted** option
> >      to avoid sorting the output.
> >
> > +    **root_id** option can be used to filter a dump to a single type and all
> > +    its dependent types. It cannot be used with any other types of filtering.
> > +
> >  bpftool btf help
> >      Print short help message.
> >
> > diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> > index 3e995faf9efa..18b037a1414b 100644
> > --- a/tools/bpf/bpftool/btf.c
> > +++ b/tools/bpf/bpftool/btf.c
> > @@ -993,6 +993,25 @@ static int do_dump(int argc, char **argv)
> >                                 goto done;
> >                         }
> >                         NEXT_ARG();
> > +               } else if (is_prefix(*argv, "root_id")) {
> > +                       __u32 root_id;
> > +                       char *end;
> > +
> > +                       if (root_type_cnt) {
> > +                               p_err("cannot use root_id with other type filtering");
> 
> this is a confusing error if the user just wanted to provide two
> root_id arguments... Also, why don't we allow multiple root_ids?
> 
> I'd bump root_type_ids[] to have something like 16 elements or
> something (though we can always do dynamic realloc as well, probably),
> and allow multiple types to be specified.
> 
> Thoughts?

That's a good point. I added this check b/c I didn't think it would
make sense to allow `root_id` filtering in combination with map dump
filtering (which uses same root_type_ids param):

        map MAP [{key | value | kv | all}]

But code can easily be tweaked to still block combination but allow
multiple `root_id`s when used alone. 16 seems sufficient to me.

Do you think it'd be more bpftool-y to require "root_id" each time or to
just take a comma separated value?
Andrii Nakryiko Dec. 13, 2024, 12:12 a.m. UTC | #3 
On Thu, Dec 12, 2024 at 3:41 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> On Thu, Dec 12, 2024 at 11:09:34AM GMT, Andrii Nakryiko wrote:
> > On Mon, Dec 9, 2024 at 3:45 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
> > >
> > > Some projects, for example xdp-tools [0], prefer to check in a minimized
> > > vmlinux.h rather than the complete file which can get rather large.
> > >
> > > However, when you try to add a minimized version of a complex struct (eg
> > > struct xfrm_state), things can get quite complex if you're trying to
> > > manually untangle and deduplicate the dependencies.
> > >
> > > This commit teaches bpftool to do a minimized dump of a single type by
> > > providing an optional root_id argument.
> > >
> > > Example usage:
> > >
> > >     $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
> > >     [12643] STRUCT 'xfrm_state' size=912 vlen=58
> > >
> > >     $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
> > >     #ifndef __VMLINUX_H__
> > >     #define __VMLINUX_H__
> > >
> > >     [..]
> > >
> > >     struct xfrm_type_offload;
> > >
> > >     struct xfrm_sec_ctx;
> > >
> > >     struct xfrm_state {
> > >             possible_net_t xs_net;
> > >             union {
> > >                     struct hlist_node gclist;
> > >                     struct hlist_node bydst;
> > >             };
> > >             union {
> > >                     struct hlist_node dev_gclist;
> > >                     struct hlist_node bysrc;
> > >             };
> > >             struct hlist_node byspi;
> > >     [..]
> > >
> > > [0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h
> > >
> > > Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> > > ---
> > >  .../bpf/bpftool/Documentation/bpftool-btf.rst |  7 +++++--
> > >  tools/bpf/bpftool/btf.c                       | 21 ++++++++++++++++++-
> > >  2 files changed, 25 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > > index 245569f43035..4899b2c10777 100644
> > > --- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > > +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > > @@ -24,7 +24,7 @@ BTF COMMANDS
> > >  =============
> > >
> > >  | **bpftool** **btf** { **show** | **list** } [**id** *BTF_ID*]
> > > -| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*]
> > > +| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*] [**root_id** *ROOT_ID*]
> > >  | **bpftool** **btf help**
> > >  |
> > >  | *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
> > > @@ -43,7 +43,7 @@ bpftool btf { show | list } [id *BTF_ID*]
> > >      that hold open file descriptors (FDs) against BTF objects. On such kernels
> > >      bpftool will automatically emit this information as well.
> > >
> > > -bpftool btf dump *BTF_SRC* [format *FORMAT*]
> > > +bpftool btf dump *BTF_SRC* [format *FORMAT*] [root_id *ROOT_ID*]
> > >      Dump BTF entries from a given *BTF_SRC*.
> > >
> > >      When **id** is specified, BTF object with that ID will be loaded and all
> > > @@ -67,6 +67,9 @@ bpftool btf dump *BTF_SRC* [format *FORMAT*]
> > >      formatting, the output is sorted by default. Use the **unsorted** option
> > >      to avoid sorting the output.
> > >
> > > +    **root_id** option can be used to filter a dump to a single type and all
> > > +    its dependent types. It cannot be used with any other types of filtering.
> > > +
> > >  bpftool btf help
> > >      Print short help message.
> > >
> > > diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> > > index 3e995faf9efa..18b037a1414b 100644
> > > --- a/tools/bpf/bpftool/btf.c
> > > +++ b/tools/bpf/bpftool/btf.c
> > > @@ -993,6 +993,25 @@ static int do_dump(int argc, char **argv)
> > >                                 goto done;
> > >                         }
> > >                         NEXT_ARG();
> > > +               } else if (is_prefix(*argv, "root_id")) {
> > > +                       __u32 root_id;
> > > +                       char *end;
> > > +
> > > +                       if (root_type_cnt) {
> > > +                               p_err("cannot use root_id with other type filtering");
> >
> > this is a confusing error if the user just wanted to provide two
> > root_id arguments... Also, why don't we allow multiple root_ids?
> >
> > I'd bump root_type_ids[] to have something like 16 elements or
> > something (though we can always do dynamic realloc as well, probably),
> > and allow multiple types to be specified.
> >
> > Thoughts?
>
> That's a good point. I added this check b/c I didn't think it would
> make sense to allow `root_id` filtering in combination with map dump
> filtering (which uses same root_type_ids param):
>
>         map MAP [{key | value | kv | all}]
>
> But code can easily be tweaked to still block combination but allow
> multiple `root_id`s when used alone. 16 seems sufficient to me.
>
> Do you think it'd be more bpftool-y to require "root_id" each time or to
> just take a comma separated value?

root_id 123 root_id 345 root_id 789

definitely more bpftool-y
diff mbox series

Patch

diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
index 245569f43035..4899b2c10777 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-btf.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
@@ -24,7 +24,7 @@  BTF COMMANDS
 =============
 
 | **bpftool** **btf** { **show** | **list** } [**id** *BTF_ID*]
-| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*]
+| **bpftool** **btf dump** *BTF_SRC* [**format** *FORMAT*] [**root_id** *ROOT_ID*]
 | **bpftool** **btf help**
 |
 | *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
@@ -43,7 +43,7 @@  bpftool btf { show | list } [id *BTF_ID*]
     that hold open file descriptors (FDs) against BTF objects. On such kernels
     bpftool will automatically emit this information as well.
 
-bpftool btf dump *BTF_SRC* [format *FORMAT*]
+bpftool btf dump *BTF_SRC* [format *FORMAT*] [root_id *ROOT_ID*]
     Dump BTF entries from a given *BTF_SRC*.
 
     When **id** is specified, BTF object with that ID will be loaded and all
@@ -67,6 +67,9 @@  bpftool btf dump *BTF_SRC* [format *FORMAT*]
     formatting, the output is sorted by default. Use the **unsorted** option
     to avoid sorting the output.
 
+    **root_id** option can be used to filter a dump to a single type and all
+    its dependent types. It cannot be used with any other types of filtering.
+
 bpftool btf help
     Print short help message.
 
diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
index 3e995faf9efa..18b037a1414b 100644
--- a/tools/bpf/bpftool/btf.c
+++ b/tools/bpf/bpftool/btf.c
@@ -993,6 +993,25 @@  static int do_dump(int argc, char **argv)
 				goto done;
 			}
 			NEXT_ARG();
+		} else if (is_prefix(*argv, "root_id")) {
+			__u32 root_id;
+			char *end;
+
+			if (root_type_cnt) {
+				p_err("cannot use root_id with other type filtering");
+				err = -EINVAL;
+				goto done;
+			}
+
+			NEXT_ARG();
+			root_id = strtoul(*argv, &end, 0);
+			if (*end) {
+				err = -1;
+				p_err("can't parse %s as root ID", *argv);
+				goto done;
+			}
+			root_type_ids[root_type_cnt++] = root_id;
+			NEXT_ARG();
 		} else if (is_prefix(*argv, "unsorted")) {
 			sort_dump_c = false;
 			NEXT_ARG();
@@ -1403,7 +1422,7 @@  static int do_help(int argc, char **argv)
 
 	fprintf(stderr,
 		"Usage: %1$s %2$s { show | list } [id BTF_ID]\n"
-		"       %1$s %2$s dump BTF_SRC [format FORMAT]\n"
+		"       %1$s %2$s dump BTF_SRC [format FORMAT] [root_id ROOT_ID]\n"
 		"       %1$s %2$s help\n"
 		"\n"
 		"       BTF_SRC := { id BTF_ID | prog PROG | map MAP [{key | value | kv | all}] | file FILE }\n"