All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Quentin Monnet <quentin.monnet@netronome.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>, bpf <bpf@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	oss-drivers@netronome.com
Subject: Re: [PATCH bpf-next v2 0/5] bpf: list BTF objects loaded on system
Date: Tue, 20 Aug 2019 09:55:03 -0700	[thread overview]
Message-ID: <CAADnVQ+ZAgmFKKKnBPt8agJ2V-f6H30OyQ104qD2vZkC=qz9wQ@mail.gmail.com> (raw)
In-Reply-To: <20190820093154.14042-1-quentin.monnet@netronome.com>

On Tue, Aug 20, 2019 at 2:32 AM Quentin Monnet
<quentin.monnet@netronome.com> wrote:
>
> Hi,
> This set adds a new command BPF_BTF_GET_NEXT_ID to the bpf() system call,
> adds the relevant API function in libbpf, and uses it in bpftool to list
> all BTF objects loaded on the system (and to dump the ids of maps and
> programs associated with them, if any).
>
> The main motivation of listing BTF objects is introspection and debugging
> purposes. By getting BPF program and map information, it should already be
> possible to list all BTF objects associated to at least one map or one
> program. But there may be unattached BTF objects, held by a file descriptor
> from a user space process only, and we may want to list them too.
>
> As a side note, it also turned useful for examining the BTF objects
> attached to offloaded programs, which would not show in program information
> because the BTF id is not copied when retrieving such info. A fix is in
> progress on that side.
>
> v2:
> - Rebase patch with new libbpf function on top of Andrii's changes
>   regarding libbpf versioning.

Applied. Thanks

      parent reply	other threads:[~2019-08-20 16:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20  9:31 [PATCH bpf-next v2 0/5] bpf: list BTF objects loaded on system Quentin Monnet
2019-08-20  9:31 ` [PATCH bpf-next v2 1/5] bpf: add new BPF_BTF_GET_NEXT_ID syscall command Quentin Monnet
2019-08-20  9:31 ` [PATCH bpf-next v2 2/5] tools: bpf: synchronise BPF UAPI header with tools Quentin Monnet
2019-08-20  9:31 ` [PATCH bpf-next v2 3/5] libbpf: refactor bpf_*_get_next_id() functions Quentin Monnet
2019-08-20  9:31 ` [PATCH bpf-next v2 4/5] libbpf: add bpf_btf_get_next_id() to cycle through BTF objects Quentin Monnet
2019-08-20  9:31 ` [PATCH bpf-next v2 5/5] tools: bpftool: implement "bpftool btf show|list" Quentin Monnet
2019-08-20 16:55 ` Alexei Starovoitov [this message]

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='CAADnVQ+ZAgmFKKKnBPt8agJ2V-f6H30OyQ104qD2vZkC=qz9wQ@mail.gmail.com' \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=quentin.monnet@netronome.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.