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

Steven Rostedt
2025-09-09T18:39:16Z

On Tue, 9 Sep 2025 17:14:35 +0100
Vincent Donnefort <vdonnefort@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 <vdonnefort@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