On Tue, Jul 7, 2015 at 11:58 PM, Steven Rostedt <[email protected]> wrote:
> On Tue, 7 Jul 2015 18:10:41 +0800
> Chunyan Zhang <[email protected]> wrote:
>
>> output_stm is a link which is used to connect trace event
>> logging with STMs, will be used in the upcoming patches.
>>
>> Signed-off-by: Chunyan Zhang <[email protected]>
>> ---
>> include/linux/trace_events.h | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
>> index 1063c85..28dcdff 100644
>> --- a/include/linux/trace_events.h
>> +++ b/include/linux/trace_events.h
>> @@ -14,6 +14,7 @@ struct trace_buffer;
>> struct tracer;
>> struct dentry;
>> struct bpf_prog;
>> +struct trace_buffer_stm;
>>
>> struct trace_print_flags {
>> unsigned long mask;
>> @@ -293,6 +294,9 @@ struct trace_event_call {
>> */
>> int flags; /* static flags of different events */
>>
>> + void (*output_stm)(struct trace_seq *tmp_seq, void *entry,
>> + struct trace_buffer_stm *tb);
>> +
>
> Shouldn't the above also have a #ifdef CONFIG_STM_TRACE_EVENT
> encompassing it? Otherwise we are adding 8 bytes to every trace event.
>
Agree. I will address this in the next version of patches.
BTW, in patch 3/4, I defined a structure variable like this:
"static struct trace_seq *stm_tmp_seq;"
It was actually the first parameter of " trace_event_stm_output_##call
" which was in the patch 4/4.
Do you think if it is an accept way to handle like this? Whether we
would have a better way instead of defining a structure variable
locally?
Thanks,
Chunyan
> -- Steve
>
>> #ifdef CONFIG_PERF_EVENTS
>> int perf_refcount;
>> struct hlist_head __percpu *perf_events;
>> @@ -412,6 +416,10 @@ enum event_trigger_type {
>> ETT_EVENT_ENABLE = (1 << 3),
>> };
>>
>> +#ifdef CONFIG_STM_TRACE_EVENT
>> +extern void stm_trace_event_write(const char *buf, unsigned len);
>> +#endif
>> +
>> extern int filter_match_preds(struct event_filter *filter, void *rec);
>>
>> extern int filter_check_discard(struct trace_event_file *file, void *rec,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
