Re: [PATCH -tip v14 07/12] tracing: Introduce TRACE_FIELD_ZERO() macro

Masami Hiramatsu
2009-08-19T02:19:54Z

Frederic Weisbecker wrote:
> On Thu, Aug 13, 2009 at 04:35:01PM -0400, Masami Hiramatsu wrote:
>> Use TRACE_FIELD_ZERO(type, item) instead of TRACE_FIELD_ZERO_CHAR(item).
>> This also includes a fix of TRACE_ZERO_CHAR() macro.
>
>
> I can't find what the fix is about (see below)

Ah, OK. This patch actually includes two parts.

One is introducing TRACE_FIELD_ZERO which is more generic than
TRACE_FIELD_ZERO_CHAR, I think.

Another is a typo fix of TRACE_ZERO_CHAR.

>>
>> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> Cc: Avi Kivity <avi@redhat.com>
>> Cc: Andi Kleen <ak@linux.intel.com>
>> Cc: Christoph Hellwig <hch@infradead.org>
>> Cc: Frank Ch. Eigler <fche@redhat.com>
>> Cc: Frederic Weisbecker <fweisbec@gmail.com>
>> Cc: H. Peter Anvin <hpa@zytor.com>
>> Cc: Ingo Molnar <mingo@elte.hu>
>> Cc: Jason Baron <jbaron@redhat.com>
>> Cc: Jim Keniston <jkenisto@us.ibm.com>
>> Cc: K.Prasad <prasad@linux.vnet.ibm.com>
>> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
>> Cc: Li Zefan <lizf@cn.fujitsu.com>
>> Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
>> Cc: Roland McGrath <roland@redhat.com>
>> Cc: Sam Ravnborg <sam@ravnborg.org>
>> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Tom Zanussi <tzanussi@gmail.com>
>> Cc: Vegard Nossum <vegard.nossum@gmail.com>
>> ---
>>
>> kernel/trace/trace_event_types.h | 4 ++--
>> kernel/trace/trace_export.c | 16 ++++++++--------
>> 2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/kernel/trace/trace_event_types.h b/kernel/trace/trace_event_types.h
>> index 6db005e..e74f090 100644
>> --- a/kernel/trace/trace_event_types.h
>> +++ b/kernel/trace/trace_event_types.h
>> @@ -109,7 +109,7 @@ TRACE_EVENT_FORMAT(bprint, TRACE_BPRINT, bprint_entry, ignore,
>> TRACE_STRUCT(
>> TRACE_FIELD(unsigned long, ip, ip)
>> TRACE_FIELD(char *, fmt, fmt)
>> - TRACE_FIELD_ZERO_CHAR(buf)
>> + TRACE_FIELD_ZERO(char, buf)
>> ),
>> TP_RAW_FMT("%08lx (%d) fmt:%p %s")
>> );
>> @@ -117,7 +117,7 @@ TRACE_EVENT_FORMAT(bprint, TRACE_BPRINT, bprint_entry, ignore,
>> TRACE_EVENT_FORMAT(print, TRACE_PRINT, print_entry, ignore,
>> TRACE_STRUCT(
>> TRACE_FIELD(unsigned long, ip, ip)
>> - TRACE_FIELD_ZERO_CHAR(buf)
>> + TRACE_FIELD_ZERO(char, buf)
>> ),
>> TP_RAW_FMT("%08lx (%d) fmt:%p %s")
>> );
>> diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
>> index 71c8d7f..b0ac92c 100644
>> --- a/kernel/trace/trace_export.c
>> +++ b/kernel/trace/trace_export.c
>> @@ -42,9 +42,9 @@ extern void __bad_type_size(void);
>> if (!ret) \
>> return 0;
>>
>> -#undef TRACE_FIELD_ZERO_CHAR
>> -#define TRACE_FIELD_ZERO_CHAR(item) \
>> - ret = trace_seq_printf(s, "\tfield:char " #item ";\t" \
>> +#undef TRACE_FIELD_ZERO
>> +#define TRACE_FIELD_ZERO(type, item) \
>> + ret = trace_seq_printf(s, "\tfield:" #type " " #item ";\t" \
>> "offset:%u;\tsize:0;\n", \
>> (unsigned int)offsetof(typeof(field), item)); \
>> if (!ret) \
>> @@ -92,9 +92,6 @@ ftrace_format_##call(struct ftrace_event_call *unused, \
>>
>> #include "trace_event_types.h"
>>
>> -#undef TRACE_ZERO_CHAR
>> -#define TRACE_ZERO_CHAR(arg)
>> -
>> #undef TRACE_FIELD
>> #define TRACE_FIELD(type, item, assign)\
>> entry->item = assign;
>> @@ -107,6 +104,9 @@ ftrace_format_##call(struct ftrace_event_call *unused, \
>> #define TRACE_FIELD_SIGN(type, item, assign, is_signed) \
>> TRACE_FIELD(type, item, assign)
>>
>> +#undef TRACE_FIELD_ZERO
>> +#define TRACE_FIELD_ZERO(type, item)
>> +
>
>
>
> Is it about the above moving?
> If so, could you just tell so that I can add something about
> it in the changelog.

No, I assume that TRACE_ZERO_CHAR is just a typo of TRACE_FIELD_ZERO_CHAR.
(because I couldn't find any other TRACE_ZERO_CHAR)

BTW, this patch may not be needed after applying patch 10/12, since
it removes ftrace event definitions of TRACE_KPROBE/KRETPROBE.

Perhaps, would I better merge and split those additional patches(and
remove this change)?
(It also could make the incremental review hard...)

Thank you,