lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 17 Nov 2010 14:02:37 +0100
From:	Peter Zijlstra <>
To:	Frederic Weisbecker <>
Cc:	Ingo Molnar <>, Darren Hart <>,
	Thomas Gleixner <>,
	LKML <>,
	Linus Torvalds <>,
	Andrew Morton <>,
	Steven Rostedt <>,
	Arjan van de Ven <>,
	Arnaldo Carvalho de Melo <>,
	Masami Hiramatsu <>,
	Tom Zanussi <>,
	Mathieu Desnoyers <>,
	Li Zefan <>,
	Jason Baron <>,
	"David S. Miller" <>,
	Christoph Hellwig <>,
	Pekka Enberg <>,
	Lai Jiangshan <>,
	Eric Dumazet <>
Subject: Re: [ANNOUNCE] New utility: 'trace'

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?!

As to the trace_printk() to perf interface, you could do like mingo did
and create a fake event and use the regular tracepoint interface, or
hook it up directly and create a PERF_RECORD_TEXT field.

Personally I like the trace_printk() as a TRACE_EVENT(printk), it also
allows removing lots of the special casing concerning trace_printk from

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists