On Tue, Jun 24, 2025 at 6:34 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > 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@xxxxxxxxx> 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 I don't see the point in all that complication. If bpf prog wants to separate its printk vs kernel printks it should use a different stream. Right now there is only stdout and stderr. Eventually we will allow for more.
