From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mel@csn.ul.ie>,
Christoph Hellwig <hch@infradead.org>,
Rik van Riel <riel@redhat.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Peter Zijlstra <peterz@infradead.org>,
Theodore Tso <tytso@mit.edu>,
Mathieu Desnoyers <compudj@krystal.dyndns.org>,
Zhaolei <zhaolei@cn.fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Jason Baron <jbaron@redhat.com>,
Jiaying Zhang <jiayingz@google.com>
Subject: Re: [RFC PATCH 2/5] tracing/events: nicer print format for parsing
Date: Wed, 10 Jun 2009 09:59:18 +0800 [thread overview]
Message-ID: <4A2F1376.7040500@cn.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0906091531090.30552@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Tue, 9 Jun 2009, Frederic Weisbecker wrote:
>>
>>> The language that is added by this patch is of the following:
>>>
>>> * FMT := constant string FMT | COMMAND FMT | empty
>>> * COMMAND := <TYPE:FIELD> | <mask:FIELD:DELIM:MASKS> | <sym:FIELD:SYMBOLS> |
>>> * <if:FIELD:TRUE:FALSE>
>>> * TYPE := int | hex | ptr | string | strarray
>>> * FIELD := defined by the event structure
>>> * MASKS := MASK=NAME,MASKS | MASK=NAME
>>> * MASK := the bit mask to match
>>> * DELIM := delimiter to separate the fields. None and ':' are both allowed
>>> * SYMBOLS := SYM=NAME,SYMBOLS | SYM=NAME
>>> * SYM := the symbol value to test against
>>> * TRUE := print when field is non zero
>>> * FALSE := print when field is zero or NULL
>>> * NAME := the name to write when a match is found
>>> *
>>> * A '\<' would print '<'
>>
>> But I wonder if the above new language is not breaking the charm
>> of the TRACE_EVENT(), which charm is that it's easy to implement (hopefully).
>>
>> Everyone knows the printk formats. And I guess this new thing is easy and
>> quick to learn. But because it's a new unknown language, the TRACE_EVENT
>> will become less readable, less reachable for newcomers in TRACE_EVENT.
>
> I tried to avoid this too, but when I started writing a tool in C that
> would parse the format file, I found that the printf was horrible.
>
> Note, I will still keep the TP_printk() macro, that will not change. The
> new macro is TP_FORMAT() that preforms the tags. Thus, if you really want
> it to print out, you can use TP_printk, but the user space tools that read
> the binary will not know how to read it unless the printk is simple.
>
> I really want to keep this language simple. If anyone has any better
> ideas, I'm all for it.
>
> I barfed when I saw this in irq_handler_entry:
>
> print fmt: "irq=%d handler=%s", REC->irq, (char *)((void *)REC + REC->__data_loc_name)
>
I barfed too when I saw this. Introducing a new format is
very meaningful. And this print format looks well.
Good Work!
I'm trying to write user-space tools. Could you tell me your tools'
developing status? And the aim of these tools? Will it be public?
I'm wandering whether I should stop this trying.
Lai.
next prev parent reply other threads:[~2009-06-10 1:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 1:45 [RFC PATCH 0/5] simplify the print fmt in the event format files Steven Rostedt
2009-06-09 1:45 ` [RFC PATCH 1/5] tracing: add trace_seq_vprint interface Steven Rostedt
2009-06-09 1:45 ` [RFC PATCH 2/5] tracing/events: nicer print format for parsing Steven Rostedt
2009-06-09 19:22 ` Frederic Weisbecker
2009-06-09 19:45 ` Steven Rostedt
2009-06-09 20:01 ` Mathieu Desnoyers
2009-06-10 1:59 ` Lai Jiangshan [this message]
2009-06-10 5:37 ` Steven Rostedt
2009-06-10 9:37 ` Christoph Hellwig
2009-06-10 9:48 ` Christoph Hellwig
2009-06-10 10:11 ` Ingo Molnar
2009-06-10 11:31 ` Frédéric Weisbecker
2009-06-10 11:51 ` Frédéric Weisbecker
2009-06-10 12:18 ` Steven Rostedt
2009-06-10 17:16 ` Ingo Molnar
2009-06-10 17:56 ` Steven Rostedt
2009-06-10 18:39 ` [PATCH][GIT PULL] tracing: do not translate event helper macros in print format Steven Rostedt
2009-06-10 20:48 ` Ingo Molnar
2009-06-11 12:52 ` Christoph Hellwig
2009-06-11 13:04 ` Steven Rostedt
2009-06-10 14:32 ` [RFC PATCH 2/5] tracing/events: nicer print format for parsing Mathieu Desnoyers
2009-06-10 12:47 ` Steven Rostedt
2009-06-09 1:45 ` [RFC PATCH 3/5] tracing/events: modify irq print to new format Steven Rostedt
2009-06-10 9:42 ` Christoph Hellwig
2009-06-10 12:23 ` Steven Rostedt
2009-06-09 1:45 ` [RFC PATCH 4/5] tracing/events: modify sched " Steven Rostedt
2009-06-09 1:45 ` [RFC PATCH 5/5] tracing/events: modify kmem " Steven Rostedt
2009-06-09 7:12 ` Peter Zijlstra
2009-06-09 8:06 ` Mel Gorman
2009-06-09 13:08 ` Steven Rostedt
2009-06-09 12:07 ` [RFC PATCH 0/5] simplify the print fmt in the event format files Ingo Molnar
2009-06-09 12:57 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A2F1376.7040500@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=compudj@krystal.dyndns.org \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=jbaron@redhat.com \
--cc=jiayingz@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=mingo@elte.hu \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tytso@mit.edu \
--cc=zhaolei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.