On Tue, 9 Sep 2025 17:14:35 +0100 Vincent Donnefort <vdonnef...@google.com> wrote:
> On Tue, Sep 09, 2025 at 09:40:28AM -0400, Steven Rostedt wrote: > > On Tue, 9 Sep 2025 13:10:25 +0100 > > Vincent Donnefort <vdonnef...@google.com> wrote: > > > > > > 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
