On ons, mar 06, 2024 at 10:15, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Mon, 04 Mar 2024 23:40:49 +0100 > Tobias Waldekranz <tobias@xxxxxxxxxxxxxx> wrote: > >> On ons, feb 28, 2024 at 09:56, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: >> > On Wed, 28 Feb 2024 11:47:24 +0100 >> > Tobias Waldekranz <tobias@xxxxxxxxxxxxxx> 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. Given that that is quite gnarly to do for the events I'm trying to trace, because of the complex object graph, would it be acceptable to format the message in the assign phase and store it as dynamic data? I.e., what (I think) you suggested at the end of your first response. My thinking is: - Managing a duplicate (flattened) object graph, exclusively for use by these tracepoints, increases the effort to keep the tracing in sync with new additions to switchdev; which I think will result in developers simply avoiding it altogether. In other words: I'd rather have somewhat inefficient but simple flashlight, rather than a very efficient one that no one knows how to change the batteries in. - This is typically not a very hot path. Most events are triggered by user configuration. Otherwise when new neighbors are discovered. - __entry->info is still there for use by raw tracepoint consumers from userspace.
