linux-kernel - Re: [PATCH 2/4] tracing: add event trace infrastructure

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-Id: <1235555831.3849.37.camel@penberg-laptop>
Date:	Wed, 25 Feb 2009 11:57:11 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Pekka Paalanen <pq@....fi>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jason Baron <jbaron@...hat.com>,
	Martin Bligh <mbligh@...gle.com>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 2/4] tracing: add event trace infrastructure

Hi Andrew,

On Wed, 2009-02-25 at 01:44 -0800, Andrew Morton wrote:
> > $ grep -v "#" trace 
> >   <idle>-0     0d..1    0us+: trace_hardirqs_off_thunk (apic_timer_interrupt)
> >   <idle>-0     0d.s.   97us : __do_softirq (do_softirq)
> >   <idle>-0     0d.s1   98us : trace_hardirqs_on (do_softirq)
> > 
> > after which you have access to the raw data. This particular trace seems
> > to be somewhat hard to parse (because not all fields are whitespace
> > delimited) but I can assure you that any format I rely on is not.
> 
> yes, but now you need to think about how this interface would have been
> designed if we'd decided to access it with something smarter than
> `cat'.
> 
> I mean, look at it.  All the multi-space column lining upping, the
> unnecessary "us" annotation, the strange symbol(symbol) thing, etc. 
> Plus it would have been more self-describing.  Right now, your parser
> has to either assume that the second character of "0d..1" is
> "irqs-off", or it has to learn how to follow ascii art lines.

Multi-space columns are probably not a big problem but sure, it's better
to keep the raw data as simple as possible and put things like units in
the header.

But anyway, I'm the wrong person to talk to if you want someone to
defend that particular format. If you find similar problems with the
kmemtrace output, then sure, by all means let me know about it and we'll
fix it up.

Note: it still make sense to have a specific kind of "pretty printing"
in the kernel. For things like kmemtrace, the amount of data gets pretty
big so it's very convenient to have "summarizing formatters" like the
histogram formatter thing that's being cooked up in ftrace tree
somewhere.

			Pekka

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/