From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Barret Rhoden <brho@google.com>,
Matt Bobrowski <mattbobrowski@google.com>,
kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v2 09/11] libbpf: Introduce bpf_prog_stream_read() API
Date: Wed, 28 May 2025 11:02:26 -0700 [thread overview]
Message-ID: <m2o6vc1uml.fsf@gmail.com> (raw)
In-Reply-To: <20250524011849.681425-10-memxor@gmail.com> (Kumar Kartikeya Dwivedi's message of "Fri, 23 May 2025 18:18:47 -0700")
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
> Introduce a libbpf API so that users can read data from a given BPF
> stream for a BPF prog fd. For now, only the low-level syscall wrapper
> is provided, we can add a bpf_program__* accessor as a follow up if
> needed.
>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
[...]
> +int bpf_prog_stream_read(int prog_fd, __u32 stream_id, void *stream_buf, __u32 stream_buf_len)
Note: many of such utility functions have _opts parameter for future
extensibility. Imo in this case it would hinder usability a bit.
If need be bpf_prog_stream_read_opts can be added later.
[...]
next prev parent reply other threads:[~2025-05-28 18:02 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 1:18 [PATCH bpf-next v2 00/11] BPF Standard Streams Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 01/11] bpf: Introduce BPF standard streams Kumar Kartikeya Dwivedi
2025-05-27 23:47 ` Eduard Zingerman
2025-05-27 23:55 ` Kumar Kartikeya Dwivedi
2025-05-28 0:23 ` Eduard Zingerman
2025-05-28 0:30 ` Kumar Kartikeya Dwivedi
2025-06-02 20:07 ` Alexei Starovoitov
2025-06-02 20:31 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 02/11] bpf: Add function to extract program source info Kumar Kartikeya Dwivedi
2025-06-02 20:18 ` Alexei Starovoitov
2025-06-02 20:21 ` Kumar Kartikeya Dwivedi
2025-06-02 20:25 ` Alexei Starovoitov
2025-06-02 20:31 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 03/11] bpf: Add function to find program from stack trace Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 04/11] bpf: Hold RCU read lock in bpf_prog_ksym_find Kumar Kartikeya Dwivedi
2025-05-24 4:41 ` Kumar Kartikeya Dwivedi
2025-05-28 0:15 ` Eduard Zingerman
2025-05-28 0:27 ` Kumar Kartikeya Dwivedi
2025-05-28 0:33 ` Eduard Zingerman
2025-05-24 1:18 ` [PATCH bpf-next v2 05/11] bpf: Add dump_stack() analogue to print to BPF stderr Kumar Kartikeya Dwivedi
2025-05-28 0:45 ` Eduard Zingerman
2025-05-28 0:58 ` Kumar Kartikeya Dwivedi
2025-05-28 6:03 ` Eduard Zingerman
2025-05-24 1:18 ` [PATCH bpf-next v2 06/11] bpf: Report may_goto timeout " Kumar Kartikeya Dwivedi
2025-06-02 22:27 ` Alexei Starovoitov
2025-06-03 1:55 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 07/11] bpf: Report rqspinlock deadlocks/timeout " Kumar Kartikeya Dwivedi
2025-06-02 22:32 ` Alexei Starovoitov
2025-06-03 2:06 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 08/11] libbpf: Add bpf_stream_printk() macro Kumar Kartikeya Dwivedi
2025-05-28 6:12 ` Eduard Zingerman
2025-05-28 10:09 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 09/11] libbpf: Introduce bpf_prog_stream_read() API Kumar Kartikeya Dwivedi
2025-05-28 18:02 ` Eduard Zingerman [this message]
2025-05-29 15:36 ` Kumar Kartikeya Dwivedi
2025-06-05 20:06 ` Andrii Nakryiko
2025-05-24 1:18 ` [PATCH bpf-next v2 10/11] bpftool: Add support for dumping streams Kumar Kartikeya Dwivedi
2025-05-27 10:20 ` Quentin Monnet
2025-05-27 14:51 ` Kumar Kartikeya Dwivedi
2025-05-24 1:18 ` [PATCH bpf-next v2 11/11] selftests/bpf: Add tests for prog streams Kumar Kartikeya Dwivedi
2025-05-28 17:04 ` Eduard Zingerman
2025-05-29 14:57 ` Kumar Kartikeya Dwivedi
2025-05-29 16:28 ` Eduard Zingerman
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=m2o6vc1uml.fsf@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brho@google.com \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=martin.lau@kernel.org \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.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.