----- On Nov 9, 2021, at 5:28 PM, rostedt rostedt@xxxxxxxxxxx wrote: > [ Hmm, should add Mathieu in on this discussion ] > > On Tue, 9 Nov 2021 17:13:13 -0500 > Jason Baron <jbaron@xxxxxxxxxx> wrote: > >> > What we are looking at there is to pass the dynamic debug descriptor to the >> > trace event filtering logic, where you could filter on information passed >> > to it. For example, on a specific file if a trace event is called by >> > several different files or modules. >> > >> > -- Steve >> >> Ok, Could this be done at the dynamic debug level as it can already match >> on specific files and line numbers currently? > > Not sure what you mean by that. > > The idea was that this would only be enabled if dynamic debug is enabled > and that the DEFINE_DYNAMIC_DEBUG_METADATA() could be used at the > tracepoint function location (trace_foo()) by the tracepoint macros. And > then if one of the callbacks registered for the tracepoint had a > "dynamic_debug" flag set, it would be passed the descriptor in as a pointer. > > And then, for example, the filtering logic of ftrace could then reference > the information of the event, if the user passed in something special. > > # echo 'DEBUG_FILE ~ "drivers/soc/qcom/*"' > events/rwmmio/rwmmio_write/filter > # echo 1 > events/rwmmio/rwmmio_write/enable > > And then only the rwmmio_write events that came from the qcom directory > would be printed. > > We would create special event fields like "DEBUG_FILE", "DEBUG_FUNC", > "DEBUG_MOD", "DEBUG_LINE", etc, that could be used if dyndebug is enabled > in the kernel. > > Of course this is going to bloat the kernel as it will create a dynamic > debug descriptor at every tracepoint location. I think there is indeed value in doing this. Where I'm not sure is regarding how we allow this to be enabled/configured. The way I see it, it might be sufficient and simpler to do just something along those lines: - Introduce a new struct tracepoint_caller_info, which would contain information about file, line number and module name where each trace_*() statement is located. - Add a new CONFIG_TRACEPOINT_CALLER_INFO which generates this new structure at build time for kernel and modules. This would indeed bloat the kernel, but it's a build-time configurable trade-off. - Change the prototype for the tracepoint callbacks to add an additional argument "struct tracepoint_caller_info *caller_info". When CONFIG_TRACEPOINT_CALLER_INFO is disabled, simply have this pointer be NULL. When CONFIG_TRACEPOINT_CALLER_INFO is enabled, pass the tracepoint's caller_info structure as parameter. It should be straightforward to adapt the tracepoint callback prototypes within each user within the Linux kernel tree. And for out-of-tree users, they have to adapt to that kind of change already anyway. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
