[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240306101557.2c56fbc6@gandalf.local.home>
Date: Wed, 6 Mar 2024 10:15:57 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Tobias Waldekranz <tobias@...dekranz.com>
Cc: Paolo Abeni <pabeni@...hat.com>, davem@...emloft.net, kuba@...nel.org,
roopa@...dia.com, razor@...ckwall.org, bridge@...ts.linux.dev,
netdev@...r.kernel.org, jiri@...nulli.us, ivecera@...hat.com,
mhiramat@...nel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v3 net-next 4/4] net: switchdev: Add tracepoints
On Mon, 04 Mar 2024 23:40:49 +0100
Tobias Waldekranz <tobias@...dekranz.com> wrote:
> On ons, feb 28, 2024 at 09:56, Steven Rostedt <rostedt@...dmis.org> wrote:
> > On Wed, 28 Feb 2024 11:47:24 +0100
> > Tobias Waldekranz <tobias@...dekranz.com> wrote:
> >
> > The "trace_seq p" is a pointer to trace_seq descriptor that can build
> > strings, and then you can use it to print a custom string in the trace
> > output.
>
> Yes I managed to decode the hidden variable :) I also found
> trace_seq_acquire() (and its macro alter ego __get_buf()), which would
> let me keep the generic stringer functions. So far, so good.
>
> I think the foundational problem remains though: TP_printk() is not
> executed until a user reads from the trace_pipe; at which point the
> object referenced by __entry->info may already be dead and
> buried. Right?
Correct. You would need to load all the information into the event data
itself, at the time of the event is triggered, that is needed to determine
how to display it.
-- Steve
Powered by blists - more mailing lists