On Fri, Nov 01 2013 at 5:39pm -0400, Steven Rostedt <srostedt@xxxxxxxxxx> wrote: > > > > > > Think this would take care of it (not full-blown tracepoints like > > > blktrace but certainly more performant than standard printk): > > What's wrong with full blown tracepoints? Nothing. Just wasn't as quick to switch to while keeping the intent of the original implementation. > > I folded this trace_printk change in and renamed from trc to trace, see: > > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=f6f5db50495b16ff23a0febf38f9ee9d964b12dd > > > > Please please please DO NOT USE TRACE_PRINTK! Sure, I'll have a look at using proper tracepoints. Worst case, in the near-term, we drop this type of patch for v3.13 considering how close we are to merge. > It's a debugging tool, and should never be used in the kernel proper. It > was meant for users to use it for debugging and then strip it out. > > Now what you could do is to set up tracepoints to record the information > you want, either in the function itself, or add the wrapper function too > as a separate policy. Not sure if that would be any help or not. > > But unless this is something that is considered "debug use only" and > never put into a production kernel, do not use trace_printk(). It really is debug only, but I cannot promise nobody will ever add a trace layer in production -- especially if it is as easy as using "trace+mq" vs "mq" when specifying the policy name. > Note, tracepoints will also give you the ability to pick and choose the > traces instead of doing it by trace_level. Yeap, I'm aware. Thanks for your feedback Steve. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
