On Wed, 06 Mar 2024 21:02:06 +0100 Tobias Waldekranz <tobias@xxxxxxxxxxxxxx> wrote: > 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. It's really up to what you want to do ;-) > > 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. How big is this info? -- Steve
