netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Quentin Monnet <quentin@isovalent.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 6/7] tools: bpftool: document and add bash completion for -L, -B options
Date: Fri, 30 Jul 2021 11:59:35 -0700	[thread overview]
Message-ID: <CAEf4Bzb+s0f6ybq+qARTpe1wa2dOD_gweBd0kQAYh3cyx=N5mQ@mail.gmail.com> (raw)
In-Reply-To: <20210729162932.30365-7-quentin@isovalent.com>

On Thu, Jul 29, 2021 at 9:29 AM Quentin Monnet <quentin@isovalent.com> wrote:
>
> The -L|--use-loader option for using loader programs when loading, or
> when generating a skeleton, did not have any documentation or bash
> completion. Same thing goes for -B|--base-btf, used to pass a path to a
> base BTF object for split BTF such as BTF for kernel modules.
>
> This patch documents and adds bash completion for those options.
>
> Fixes: 75fa1777694c ("tools/bpftool: Add bpftool support for split BTF")
> Fixes: d510296d331a ("bpftool: Use syscall/loader program in "prog load" and "gen skeleton" command.")
> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
> ---
> Note: The second example with base BTF in the BTF man page assumes that
> dumping split BTF when objects are passed by id is supported. Support is
> currently pending review in another PR.
> ---

Not anymore :)

[...]

> @@ -73,6 +74,20 @@ OPTIONS
>  =======
>         .. include:: common_options.rst
>
> +       -B, --base-btf *FILE*
> +                 Pass a base BTF object. Base BTF objects are typically used
> +                 with BTF objects for kernel modules. To avoid duplicating
> +                 all kernel symbols required by modules, BTF objects for
> +                 modules are "split", they are built incrementally on top of
> +                 the kernel (vmlinux) BTF object. So the base BTF reference
> +                 should usually point to the kernel BTF.
> +
> +                 When the main BTF object to process (for example, the
> +                 module BTF to dump) is passed as a *FILE*, bpftool attempts
> +                 to autodetect the path for the base object, and passing
> +                 this option is optional. When the main BTF object is passed
> +                 through other handles, this option becomes necessary.
> +
>  EXAMPLES
>  ========
>  **# bpftool btf dump id 1226**
> @@ -217,3 +232,34 @@ All the standard ways to specify map or program are supported:
>  **# bpftool btf dump prog tag b88e0a09b1d9759d**
>
>  **# bpftool btf dump prog pinned /sys/fs/bpf/prog_name**
> +
> +|
> +| **# bpftool btf dump file /sys/kernel/btf/i2c_smbus**
> +| (or)
> +| **# I2C_SMBUS_ID=$(bpftool btf show -p | jq '.[] | select(.name=="i2c_smbus").id')**
> +| **# bpftool btf dump id ${I2C_SMBUS_ID} -B /sys/kernel/btf/vmlinux**
> +
> +::
> +
> +  [104848] STRUCT 'i2c_smbus_alert' size=40 vlen=2
> +          'alert' type_id=393 bits_offset=0
> +          'ara' type_id=56050 bits_offset=256
> +  [104849] STRUCT 'alert_data' size=12 vlen=3
> +          'addr' type_id=16 bits_offset=0
> +          'type' type_id=56053 bits_offset=32
> +          'data' type_id=7 bits_offset=64
> +  [104850] PTR '(anon)' type_id=104848
> +  [104851] PTR '(anon)' type_id=104849
> +  [104852] FUNC 'i2c_register_spd' type_id=84745 linkage=static
> +  [104853] FUNC 'smbalert_driver_init' type_id=1213 linkage=static
> +  [104854] FUNC_PROTO '(anon)' ret_type_id=18 vlen=1
> +          'ara' type_id=56050
> +  [104855] FUNC 'i2c_handle_smbus_alert' type_id=104854 linkage=static
> +  [104856] FUNC 'smbalert_remove' type_id=104854 linkage=static
> +  [104857] FUNC_PROTO '(anon)' ret_type_id=18 vlen=2
> +          'ara' type_id=56050
> +          'id' type_id=56056
> +  [104858] FUNC 'smbalert_probe' type_id=104857 linkage=static
> +  [104859] FUNC 'smbalert_work' type_id=9695 linkage=static
> +  [104860] FUNC 'smbus_alert' type_id=71367 linkage=static
> +  [104861] FUNC 'smbus_do_alert' type_id=84827 linkage=static

This reminded be that it would be awesome to support "format c"
use-case for dumping split BTF in a more sane way. I.e., instead of
dumping all types from base and split BTF, only dump necessary (used)
forward declarations from base BTF, and then full C dump of only new
types from the split (module) BTF. This will become more important as
people will start using module BTF more. It's an interesting add-on to
libbpf's btf_dumper functionality. Not sure how hard that would be,
but I'd imagine it shouldn't require much changes.

Just in case anyone wanted to challenge themselves with some more
algorithmic patch for libbpf (*wink wink*)...


> diff --git a/tools/bpf/bpftool/Documentation/bpftool-gen.rst b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> index 709b93fe1da3..2ef2f2df0279 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> @@ -12,7 +12,8 @@ SYNOPSIS
>
>         **bpftool** [*OPTIONS*] **gen** *COMMAND*
>
> -       *OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] | { **-d** | **--debug** } }
> +       *OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] | { **-d** | **--debug** } |
> +               { **-L** | **--use-loader** } }
>
>         *COMMAND* := { **object** | **skeleton** | **help** }
>

[...]

  reply	other threads:[~2021-07-30 18:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 16:29 [PATCH bpf-next 0/7] tools: bpftool: update, synchronise and Quentin Monnet
2021-07-29 16:29 ` [PATCH bpf-next 1/7] tools: bpftool: slightly ease bash completion updates Quentin Monnet
2021-07-30 18:45   ` Andrii Nakryiko
2021-07-30 21:46     ` Quentin Monnet
2021-07-30 21:54       ` Andrii Nakryiko
2021-07-29 16:29 ` [PATCH bpf-next 2/7] selftests/bpf: check consistency between bpftool source, doc, completion Quentin Monnet
2021-07-29 16:29 ` [PATCH bpf-next 3/7] tools: bpftool: complete and synchronise attach or map types Quentin Monnet
2021-07-30 18:52   ` Andrii Nakryiko
2021-07-30 21:47     ` Quentin Monnet
2021-07-29 16:29 ` [PATCH bpf-next 4/7] tools: bpftool: update and synchronise option list in doc and help msg Quentin Monnet
2021-07-29 16:29 ` [PATCH bpf-next 5/7] selftests/bpf: update bpftool's consistency script for checking options Quentin Monnet
2021-07-29 16:29 ` [PATCH bpf-next 6/7] tools: bpftool: document and add bash completion for -L, -B options Quentin Monnet
2021-07-30 18:59   ` Andrii Nakryiko [this message]
2021-07-30 21:48     ` Quentin Monnet
2021-07-30 22:10       ` Andrii Nakryiko
2021-07-29 16:29 ` [PATCH bpf-next 7/7] tools: bpftool: complete metrics list in "bpftool prog profile" doc Quentin Monnet
2021-07-30 19:06 ` [PATCH bpf-next 0/7] tools: bpftool: update, synchronise and Andrii Nakryiko
2021-07-30 21:48   ` Quentin Monnet
2021-07-30 21:58     ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEf4Bzb+s0f6ybq+qARTpe1wa2dOD_gweBd0kQAYh3cyx=N5mQ@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=quentin@isovalent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).