lkml.org 
[lkml]   [2009]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/5] simplify the print fmt in the event format files

* Steven Rostedt <rostedt@goodmis.org> wrote:

>
> This is a request for comments on the new print format style to show
> in the format file.
>
> As more and more users of ftrace are retrieving their data through
> the binary interface, it has become more important to be able to
> parse the format of these binary records.
>
> Since the output may also be used in dumps of the kernel, it is still
> important that ftrace has a way within the kernel to display the
> data records in a human readable format.
>
> The current method is with TP_printk, in the TRACE_EVENT. This acts
> just like a printk and lets the developer print out their format
> anyway they would like to. But the problem with this is that the
> readers of the binary data would either have to have a C parser to understand
> the output, or would have to have a custom made parser to match the
> contents, and hope that the contents would not change.
>
> This patch series creates a new marco called TP_FORMAT that can be
> used in place of the TP_printk inside the TRACE_EVENT macro.
>
> This format has the current following language:
>
> * 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 '<'
>
> We can extend this langange when we need to. A user app could just
> ignore a type it does not understand.
>
> This is an RFC patch set. I basically just got it working but it lacks
> some clean ups on errors. And I need to investigate the use of the
> fields structures to make sure they are adquately protected. It uses
> the fields that are pased by the filter code.
>
> This makes the output of the format much cleaner.

Agreed, it's clearly cleaner.

>
> We go from this:
>
> print fmt: "irq=%d handler=%s", REC->irq, (char *)((void *)REC + REC->__data_loc_name)
>
> to this:
>
> format: irq=<int:irq> handler=<string:name>
>
> and this:
>
> print fmt: "softirq=%d action=%s", REC->vec, ({ static const struct trace_print_flags symbols[] = { { HI_SOFTIRQ, "HI" }, { TIMER_SOFTIRQ, "TIMER" }, { NET_TX_SOFTIRQ, "NET_TX" }, { NET_RX_SOFTIRQ, "NET_RX" }, { BLOCK_SOFTIRQ, "BLOCK" }, { TASKLET_SOFTIRQ, "TASKLET" }, { SCHED_SOFTIRQ, "SCHED" }, { HRTIMER_SOFTIRQ, "HRTIMER" }, { RCU_SOFTIRQ, "RCU" }, { -1, ((void *)0) }}; ftrace_print_symbols_seq (p, REC->vec, symbols); })
>
> To this:
>
> format: softirq=<int:vec> action=<sym:vec:0=HI,1=TIMER,2=NET_TX,3=NET_RX,4=BLOCK,5=TASKLET,6=SCHED,7=HRTIMER,8=RCU

Introducing new, elaborate description languages is always risky.
Would there be a way to reuse something existing - ideally some nice
sub-set of C structure definitions?

Also, would it be possible to put more newlines into the format, so
that human inspection is more straightforward. It wont matter to the
tools.

Ingo


\
 
 \ /
  Last update: 2009-06-09 14:11    [W:0.253 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site