Messages in this thread | | | Date | Wed, 17 Nov 2010 08:49:03 -0800 | From | Darren Hart <> | Subject | Re: [ANNOUNCE] New utility: 'trace' |
| |
On 11/17/2010 05:02 AM, Peter Zijlstra wrote: > On Wed, 2010-11-17 at 13:53 +0100, Frederic Weisbecker wrote: >> On Wed, Nov 17, 2010 at 12:35:50PM +0100, Peter Zijlstra wrote: >>> On Wed, 2010-11-17 at 09:30 +0100, Ingo Molnar wrote: >>>>> For example I'm currently working with dozens of trace_printk() and I would be >>>>> very happy to turn some of them off half of the time. >>>> >>>> I guess we could try such a patch. If you send a prototype i'd be interested in >>>> testing it out. >>> >>> I don't see the point, the kernel shouldn't contain any trace_printk()s >>> to begin with.. >> >> >> It's oriented toward developers. Those who use dozens of tracepoints in >> their tree because they are debugging something or developing a new feature, >> they might to deactivate/reactivate some of these independant points. >> >> This can also apply to dynamic_printk of course. >> >> Well, the very first and main point is to standardize trace_printk into >> a trace event so that it gets usable by perf tools. I have been asked many >> times "how to use trace_printk() with perf?". > > Thing is, since its these dev who add the trace_printk()s to begin with, > I don't see the point in splitting them out, if you didn't want them why > did you add them to begin with?!
What I understood from Frederic's email was that during a debug session it is sometimes helpful to be able to enable and disable the trace_printk's. This makes sense as it reduces the number of kernel build/reboot cycles. However, I would think most of that could be accomplished with some judicious message tagging and post-processing to filter out the unwanted trace_printk's. The only exception might be when the trace_printk's add enough overhead to mask a timing related bug. In this case, I'd probably be tempted to remove the stubs anyway.
-- Darren Hart Yocto Linux Kernel
| |