Thread (48 messages) 48 messages, 4 authors, 2025-09-12

Re: [PATCH v6 04/24] tracing: Add reset to trace remotes

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2025-09-09 18:39:06
Also in: kvmarm, linux-arm-kernel, lkml

On Tue, 9 Sep 2025 17:14:35 +0100
Vincent Donnefort [off-list ref] wrote:
On Tue, Sep 09, 2025 at 09:40:28AM -0400, Steven Rostedt wrote:
quoted
On Tue, 9 Sep 2025 13:10:25 +0100
Vincent Donnefort [off-list ref] wrote:
  
quoted
quoted
I wonder if we should name the file "reset" to not be confusing to users
when they cat the file and it doesn't produce any output.    
My idea was to keep the exact same interface as the rest of the tracing. I could
keep that /trace file for compatibility and add /reset?

"cat trace" could also just returns a text like *** not supported *** ?  
If it's never going to be supported, I rather not add it. It not being
there is a sure way of knowing it's not supported. Just adding it because
the normal system has it is actually worse if it doesn't behave the same.  
If later we extend the meta-page to support non-consuming read, /trace would
then become useful.

Another argument for non-consuming read would be to enable dump on panic.

But I understand your point, it might be wishful thinking at this point.
It may be possible to still do a trace file. Basically, it would work the
same way the normal iterator works. Today it reads the trace while the
writer could be modifying it.

Actually, I think there's a bug in the iterator code today :-p

It needs to be modified to copy the event, as it currently passes the event
as is and that event could be written over by the writer.

But anyway, I think it should work for the remote buffers too. Let me go
and fix the current iterator.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help