From: Alan Maguire <alan.maguire@oracle.com>
To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org
Cc: martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@google.com, haoluo@google.com,
jolsa@kernel.org, bpf@vger.kernel.org
Subject: Re: [RFC bpf-next 0/2] libbpf Userspace Runtime-Defined Tracing (URDT)
Date: Fri, 2 Feb 2024 14:47:58 +0000 [thread overview]
Message-ID: <eb6c9222-7c08-4758-a0ce-94a91ddd560d@oracle.com> (raw)
In-Reply-To: <20240131162003.962665-1-alan.maguire@oracle.com>
On 31/01/2024 16:20, Alan Maguire wrote:
> Adding userspace tracepoints in other languages like python and
> go is a very useful for observability. libstapsdt [1]
> and language bindings like python-stapsdt [2] that rely on it
> use a clever scheme of emulating static (USDT) userspace tracepoints
> at runtime. This involves (as I understand it):
>
> - fabricating a shared library
> - annotating it with ELF notes that describe its tracepoints
> - dlopen()ing it and calling the appropriate probe fire function
> to trigger probe firing.
>
> bcc already supports this mechanism (the examples in [2] use
> bcc to list/trigger the tracepoints), so it seems like it
> would be a good candidate for adding support to libbpf.
>
> However, before doing that, it's worth considering if there
> are simpler ways to support runtime probe firing. This
> small series demonstrates a simple method based on USDT
> probes added to libbpf itself.
>
[snip]
> The useful thing about this is that by attaching to
> libbpf.so (and firing probes using that library) we
> can get system-wide dynamic probe firing. It is also
> easy to fire a dynamic probe - no setup is required.
>
> More examples of auto and manual attach can be found in
> the selftests (patch 2).
>
> If this approach appears to be worth pursing, we could
> also look at adding support to libstapsdt for it.
>
Proof-of-concept libstapsdt support has been built and tested;
consumers of libstapsdt continue to work the same way but
with URDT support, we can trace dynamic events system-wide.
See
https://github.com/linux-usdt/libstapsdt/compare/main...alan-maguire:libstapsdt:urdt
> Alan Maguire (2):
> libbpf: add support for Userspace Runtime Dynamic Tracing (URDT)
> selftests/bpf: add tests for Userspace Runtime Defined Tracepoints
> (URDT)
>
> tools/lib/bpf/Build | 2 +-
> tools/lib/bpf/Makefile | 2 +-
> tools/lib/bpf/libbpf.c | 94 ++++++++++
> tools/lib/bpf/libbpf.h | 94 ++++++++++
> tools/lib/bpf/libbpf.map | 13 ++
> tools/lib/bpf/libbpf_internal.h | 2 +
> tools/lib/bpf/urdt.bpf.h | 103 +++++++++++
> tools/lib/bpf/urdt.c | 145 +++++++++++++++
> tools/testing/selftests/bpf/Makefile | 2 +-
> tools/testing/selftests/bpf/prog_tests/urdt.c | 173 ++++++++++++++++++
> tools/testing/selftests/bpf/progs/test_urdt.c | 100 ++++++++++
> .../selftests/bpf/progs/test_urdt_shared.c | 59 ++++++
> 12 files changed, 786 insertions(+), 3 deletions(-)
> create mode 100644 tools/lib/bpf/urdt.bpf.h
> create mode 100644 tools/lib/bpf/urdt.c
> create mode 100644 tools/testing/selftests/bpf/prog_tests/urdt.c
> create mode 100644 tools/testing/selftests/bpf/progs/test_urdt.c
> create mode 100644 tools/testing/selftests/bpf/progs/test_urdt_shared.c
>
next prev parent reply other threads:[~2024-02-02 14:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 16:20 [RFC bpf-next 0/2] libbpf Userspace Runtime-Defined Tracing (URDT) Alan Maguire
2024-01-31 16:20 ` [RFC bpf-next 1/2] libbpf: add support for Userspace Runtime Dynamic " Alan Maguire
2024-01-31 16:20 ` [RFC bpf-next 2/2] selftests/bpf: add tests for Userspace Runtime Defined Tracepoints (URDT) Alan Maguire
2024-01-31 17:06 ` [RFC bpf-next 0/2] libbpf Userspace Runtime-Defined Tracing (URDT) Daniel Xu
2024-01-31 17:38 ` Alan Maguire
2024-01-31 18:01 ` Daniel Xu
2024-02-02 14:47 ` Alan Maguire [this message]
2024-02-02 21:39 ` Andrii Nakryiko
2024-02-06 9:49 ` Alan Maguire
2024-02-08 0:05 ` 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=eb6c9222-7c08-4758-a0ce-94a91ddd560d@oracle.com \
--to=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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