Messages in this thread |  | | | Date | Wed, 17 Nov 2010 15:10:33 +0100 | | From | Frederic Weisbecker <> | | Subject | Re: [ANNOUNCE] New utility: 'trace' |
| |
On Wed, Nov 17, 2010 at 02:53:49PM +0100, Peter Zijlstra wrote: > On Wed, 2010-11-17 at 14:43 +0100, Frederic Weisbecker wrote: > > > > > Yes, trace_printk() is a pure debug interface, solely meant for the edit > > > + reboot cycle. > > > > So why prevent from making it even more handy? > > > > > > > If you want anything more than that we've got tracepoints. The rule up > > > until now has been to never merge a trace_printk() user. > > > > Sure, that doesn't change the core idea of trace_prink(): none of them must > > be merged. That new event interface would just make private uses of trace_printk() > > more convenient. > > I don't get it, if you don't want it, why put it there in the first > place? > > I've never found myself thinking, oh damn, I didn't want to see that > one!, only damn, I should have added more :-)
Hehe :)
Yeah I have a strange workflow. I'm working on that CPU isolation thing and I have dozens of trace_printk all over the place for tons of things. And everytime I remove one to unwind some output or to focus on another one, I often have to restore it later because I need it again. Usually I even just comment it out instead of removing it.
If I could make this dynamically on a per line filtering, or sometimes on a per file granularity (as both are equally often the case for me), I would probably win some time.
I just don't know how many developers have a similar workflow than mine.
|  |