Re: [PATCH] tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event macro

[Frederic Weisbecker <fweisbec@gmail.com>]

On Sat, Sep 12, 2009 at 03:56:52PM -0400, Steven Rostedt wrote:
> On Tue, 2009-03-31 at 00:49 -0500, Tom Zanussi wrote:
> > Frederic Weisbecker suggested that the trace_special event shouldn't be
> > filterable; this patch adds a TRACE_EVENT_FORMAT_NOFILTER event macro
> > that allows an event format to be exported without having a filter
> > attached, and removes filtering from the trace_special event.
> > 
> 
> Frederic,
> 
> Do you remember why trace_special should not be filtered? I think
> earlier we use to use it for lots of special markings, but now that we
> have trace_printk, at least I have not used it in a long time.
> 
> Reason why I'm asking, is that I've wrote a patch that automates the
> format of the debugfs/tracing/events/ftrace/* files. I'm using macros
> like we have in include/trace/events/ to create the ftrace internal
> structures. This way we get rid of the manual exporting of that
> directory and now the formats will be automatically match the ring
> buffer internals.
> 
> This also adds some entries that were not ported, just because it is
> automated we get all of them. I'm thinking it would be more powerful to
> let all ftrace entries be filtered. Even the trace_printks.
> 
> What do you think?
> 
> -- Steve



It's not that it would harm but it would be meaningless.
The tracer that uses the special entry is the only one
that can give sense to it.

Sysprof is the only user IIRC.

If I'm not wrong, the first field gives the sense of the other fields:

0 -> pid
1 -> backtrace node
2 -> backtrace node (userland)
3 -> backtrace overflow

Well, actually while thinking more about it, we may want to
filter with "arg0 == 1 && arg1 == addr_to_filter_in_a_callchain" or things like
that.

So I guess actually that could be useful.
I did not think about it at that time...