On Fri, 30 May 2014 19:58:52 -0700
Todd E Brandt [off-list ref] wrote:

quoted

This will export the strings into debugfs/tracing/printk_formats so
that the pointer can be mapped to a string.

ahh, ok, yea if there's some performance impact of using tracepoints this
way then I'll definately change that, thanks for the example.

It speeds up the tracing and compacts it a bit. It has no affect when
tracing is disabled.

quoted

This is assuming that all of these calls are in core kernel code and
not in modules. Are they?

No these are all core code. I double-checked all the Kconfigs to make
sure none of those files are configured by tristate options, they're
all bool. I also test ran a few compiles with CONFIG_PM disabled just
to be sure that nothing broke in kernel/cpu.c and all was well.

After checking, it didn't really matter if they were used by modules or
not. Just that their strings were all constants.
 

quoted

Here you would have:

	TP_printk("%s[%u] %s", entry->action,

You just need to add that TPS() around all strings where it is passed
to the tracepoint and it will still work with trace-cmd and perf.

Is is legal to pass a format string to a tracepoint which then gets fed
into TP_printk? i.e.

TP_printk(__get_str(fmtstring), __entry->val)

I didn't do that since I couldn't find a single example of that in the other
trace events, but theoretically it should be safe.

Hmm, was there an example where you wanted that? That's not what I was
suggesting. It may work for a tracepoint, but it will definitely screw
up trace-cmd and perf.

-- Steve