From: Jiri Olsa <olsajiri@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
bpf@vger.kernel.org, Eduard Zingerman <eddyz87@gmail.com>,
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 v3 02/12] bpf: Introduce BPF standard streams
Date: Tue, 24 Jun 2025 15:34:46 +0200 [thread overview]
Message-ID: <aFqpdkLaRsjTw7Ik@krava> (raw)
In-Reply-To: <CAP01T77EXWDdRYtrJHUR6qLBgLqe4oT0A0N74CGBBRVGYPuKnQ@mail.gmail.com>
On Tue, Jun 24, 2025 at 02:15:09PM +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue, 24 Jun 2025 at 14:01, Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Mon, Jun 23, 2025 at 08:12:42PM -0700, Kumar Kartikeya Dwivedi wrote:
> > > Add support for a stream API to the kernel and expose related kfuncs to
> > > BPF programs. Two streams are exposed, BPF_STDOUT and BPF_STDERR. These
> > > can be used for printing messages that can be consumed from user space,
> > > thus it's similar in spirit to existing trace_pipe interface.
> > >
> > > The kernel will use the BPF_STDERR stream to notify the program of any
> > > errors encountered at runtime. BPF programs themselves may use both
> > > streams for writing debug messages. BPF library-like code may use
> > > BPF_STDERR to print warnings or errors on misuse at runtime.
> >
> > just curious, IIUC we can't mix the output of the streams when we dump
> > them, right? I wonder it'd be handy to be able to get combined output
> > and see messages from bpf programs sorted out with messages from kernel
> >
>
> Yeah, this is a good point.
> Right now, no, in the sense that sequentiality is definitely broken
> across the two streams.
> We can force print a timestamp for every message and do the sorting
> from bpftool side, or it can just be piped to sort after dumping both
> stdout and stderr.
> Output will look like trace_pipe with some fixed format before the
> actual message.
> WDYT? Others are also welcome to chime in.
yes, keeping the kernel simple (just adding timestamp) and sorting
it in bpftool seems good to me
jirka
next prev parent reply other threads:[~2025-06-24 13:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 3:12 [PATCH bpf-next v3 00/12] BPF Standard Streams Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 01/12] bpf: Refactor bprintf buffer support Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 02/12] bpf: Introduce BPF standard streams Kumar Kartikeya Dwivedi
2025-06-24 12:01 ` Jiri Olsa
2025-06-24 12:15 ` Kumar Kartikeya Dwivedi
2025-06-24 13:34 ` Jiri Olsa [this message]
2025-06-24 16:03 ` Alexei Starovoitov
2025-06-24 18:06 ` Alexei Starovoitov
2025-06-24 3:12 ` [PATCH bpf-next v3 03/12] bpf: Add function to extract program source info Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 04/12] bpf: Ensure RCU lock is held around bpf_prog_ksym_find Kumar Kartikeya Dwivedi
2025-06-24 17:45 ` Alexei Starovoitov
2025-06-24 3:12 ` [PATCH bpf-next v3 05/12] bpf: Add function to find program from stack trace Kumar Kartikeya Dwivedi
2025-06-24 17:46 ` Alexei Starovoitov
2025-06-24 3:12 ` [PATCH bpf-next v3 06/12] bpf: Add dump_stack() analogue to print to BPF stderr Kumar Kartikeya Dwivedi
2025-06-24 11:38 ` Jiri Olsa
2025-06-24 11:49 ` Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 07/12] bpf: Report may_goto timeout " Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 08/12] bpf: Report rqspinlock deadlocks/timeout " Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 09/12] libbpf: Add bpf_stream_printk() macro Kumar Kartikeya Dwivedi
2025-06-25 20:01 ` Andrii Nakryiko
2025-06-24 3:12 ` [PATCH bpf-next v3 10/12] libbpf: Introduce bpf_prog_stream_read() API Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 11/12] bpftool: Add support for dumping streams Kumar Kartikeya Dwivedi
2025-06-24 3:12 ` [PATCH bpf-next v3 12/12] selftests/bpf: Add tests for prog streams Kumar Kartikeya Dwivedi
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=aFqpdkLaRsjTw7Ik@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brho@google.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--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 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).