Ingo,
Please pull the latest tip/tracing/filters tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/tracing/filters
Steven Rostedt (2):
ring-buffer: add ring_buffer_discard_commit
tracing/filters: use ring_buffer_discard_commit for discarded events
Tom Zanussi (2):
tracing/filters: add run-time field descriptions to TRACE_EVENT_FORMAT events
tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event macro
----
include/linux/ring_buffer.h | 29 ++++++++
kernel/trace/kmemtrace.c | 6 ++
kernel/trace/ring_buffer.c | 125 +++++++++++++++++++++++++++++------
kernel/trace/trace.c | 32 ++++++++-
kernel/trace/trace.h | 23 +++++++
kernel/trace/trace_branch.c | 3 +
kernel/trace/trace_event_types.h | 8 ++-
kernel/trace/trace_events.c | 7 ++
kernel/trace/trace_events_filter.c | 4 +-
kernel/trace/trace_events_stage_2.h | 7 --
kernel/trace/trace_events_stage_3.h | 6 +-
kernel/trace/trace_export.c | 90 ++++++++++++++++++++++++-
kernel/trace/trace_hw_branches.c | 2 +
kernel/trace/trace_power.c | 4 +
14 files changed, 305 insertions(+), 41 deletions(-)
--
--
On Thu, 2 Apr 2009, Steven Rostedt wrote:
>
> Ingo,
>
> Please pull the latest tip/tracing/filters tree, which can be found at:
Ingo,
Also note, I had to merge your kmemtrace tree into the filters branch
because there where some updates that Tom based his changes on.
-- Steve
* Steven Rostedt <[email protected]> wrote:
>
> Ingo,
>
> Please pull the latest tip/tracing/filters tree, which can be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> tip/tracing/filters
>
>
> Steven Rostedt (2):
> ring-buffer: add ring_buffer_discard_commit
> tracing/filters: use ring_buffer_discard_commit for discarded events
>
> Tom Zanussi (2):
> tracing/filters: add run-time field descriptions to TRACE_EVENT_FORMAT events
> tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event macro
I've cherry-picked them into tip/tracing/filters, and there are some
new build failures:
(.text+0x40795): undefined reference to `event_context_switch'
kernel/built-in.o: In function `probe_power_mark':
trace_power.c:(.text+0x44fd7): undefined reference to `event_power'
trace_power.c:(.text+0x44fe1): undefined reference to `event_power'
trace_power.c:(.text+0x44fe6): undefined reference to
`filter_match_preds'
kernel/built-in.o: In function `probe_power_end':
trace_power.c:(.text+0x45064): undefined reference to `event_power'
trace_power.c:(.text+0x4506e): undefined reference to `event_power'
trace_power.c:(.text+0x45073): undefined reference to
`filter_match_preds'
kernel/built-in.o: In function `kmemtrace_free':
so i've excluded it from tip/master for now.
Ingo
On Fri, 3 Apr 2009, Ingo Molnar wrote:
>
> * Steven Rostedt <[email protected]> wrote:
>
> >
> > Ingo,
> >
> > Please pull the latest tip/tracing/filters tree, which can be found at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > tip/tracing/filters
> >
> >
> > Steven Rostedt (2):
> > ring-buffer: add ring_buffer_discard_commit
> > tracing/filters: use ring_buffer_discard_commit for discarded events
> >
> > Tom Zanussi (2):
> > tracing/filters: add run-time field descriptions to TRACE_EVENT_FORMAT events
> > tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event macro
>
> I've cherry-picked them into tip/tracing/filters, and there are some
> new build failures:
>
> (.text+0x40795): undefined reference to `event_context_switch'
> kernel/built-in.o: In function `probe_power_mark':
> trace_power.c:(.text+0x44fd7): undefined reference to `event_power'
> trace_power.c:(.text+0x44fe1): undefined reference to `event_power'
> trace_power.c:(.text+0x44fe6): undefined reference to
> `filter_match_preds'
> kernel/built-in.o: In function `probe_power_end':
> trace_power.c:(.text+0x45064): undefined reference to `event_power'
> trace_power.c:(.text+0x4506e): undefined reference to `event_power'
> trace_power.c:(.text+0x45073): undefined reference to
> `filter_match_preds'
> kernel/built-in.o: In function `kmemtrace_free':
>
> so i've excluded it from tip/master for now.
I figured that is due to the missing pieces from the ftrace merge I did.
But I guess we want to tone down on the inter merging of branches.
Tom, could you check out the tracing/filters branch from tip and get that
branch working.
Thanks,
-- Steve
On Fri, 2009-04-03 at 10:36 -0400, Steven Rostedt wrote:
> On Fri, 3 Apr 2009, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <[email protected]> wrote:
> >
> > >
> > > Ingo,
> > >
> > > Please pull the latest tip/tracing/filters tree, which can be found at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
> > > tip/tracing/filters
> > >
> > >
> > > Steven Rostedt (2):
> > > ring-buffer: add ring_buffer_discard_commit
> > > tracing/filters: use ring_buffer_discard_commit for discarded events
> > >
> > > Tom Zanussi (2):
> > > tracing/filters: add run-time field descriptions to TRACE_EVENT_FORMAT events
> > > tracing/filters: add TRACE_EVENT_FORMAT_NOFILTER event macro
> >
> > I've cherry-picked them into tip/tracing/filters, and there are some
> > new build failures:
> >
> > (.text+0x40795): undefined reference to `event_context_switch'
> > kernel/built-in.o: In function `probe_power_mark':
> > trace_power.c:(.text+0x44fd7): undefined reference to `event_power'
> > trace_power.c:(.text+0x44fe1): undefined reference to `event_power'
> > trace_power.c:(.text+0x44fe6): undefined reference to
> > `filter_match_preds'
> > kernel/built-in.o: In function `probe_power_end':
> > trace_power.c:(.text+0x45064): undefined reference to `event_power'
> > trace_power.c:(.text+0x4506e): undefined reference to `event_power'
> > trace_power.c:(.text+0x45073): undefined reference to
> > `filter_match_preds'
> > kernel/built-in.o: In function `kmemtrace_free':
> >
> > so i've excluded it from tip/master for now.
>
> I figured that is due to the missing pieces from the ftrace merge I did.
> But I guess we want to tone down on the inter merging of branches.
>
> Tom, could you check out the tracing/filters branch from tip and get that
> branch working.
>
I'm guessing the problem is that CONFIG_EVENT_TRACER wasn't selected but
should have been, because those tracers all now export events
(trace_event_types.h, included by trace_export.c). I'm not sure this is
the right way to do it, but the patch below selects EVENT_TRACER if
TRACING is selected (a couple of the exported events belong to bprint
and print, which don't have a config option other than TRACING, so it
seems to belong there).
Signed-off-by: Tom Zanussi <[email protected]>
---
kernel/trace/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 8a41360..a061746 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -56,6 +56,7 @@ config TRACING
select TRACEPOINTS
select NOP_TRACER
select BINARY_PRINTF
+ select EVENT_TRACER
#
# Minimum requirements an architecture has to meet for us to
@@ -177,7 +178,7 @@ config CONTEXT_SWITCH_TRACER
config EVENT_TRACER
bool "Trace various events in the kernel"
- select TRACING
+ depends on TRACING
help
This tracer hooks to various trace points in the kernel
allowing the user to pick and choose which trace point they
--
1.5.6.3
On Sat, 4 Apr 2009, Tom Zanussi wrote:
> On Fri, 2009-04-03 at 10:36 -0400, Steven Rostedt wrote:
>
> I'm guessing the problem is that CONFIG_EVENT_TRACER wasn't selected but
> should have been, because those tracers all now export events
> (trace_event_types.h, included by trace_export.c). I'm not sure this is
> the right way to do it, but the patch below selects EVENT_TRACER if
> TRACING is selected (a couple of the exported events belong to bprint
> and print, which don't have a config option other than TRACING, so it
> seems to belong there).
>
> Signed-off-by: Tom Zanussi <[email protected]>
>
> ---
> kernel/trace/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 8a41360..a061746 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -56,6 +56,7 @@ config TRACING
> select TRACEPOINTS
> select NOP_TRACER
> select BINARY_PRINTF
> + select EVENT_TRACER
Yeah, we can do this.
>
> #
> # Minimum requirements an architecture has to meet for us to
> @@ -177,7 +178,7 @@ config CONTEXT_SWITCH_TRACER
>
> config EVENT_TRACER
> bool "Trace various events in the kernel"
> - select TRACING
> + depends on TRACING
This means we can only select EVENT_TRACER if something else has been
selected. Can't we keep the "select TRACING" here.
That way, we could just select EVENT_TRACER, but if anything other
tracer is selected, we automatically get EVENT_TRACER.
The logic would be, if you pick any tracer you get the EVENT_TRACER.
But you can still just ask for the EVENT_TRACER with no other tracer.
-- Steve
> help
> This tracer hooks to various trace points in the kernel
> allowing the user to pick and choose which trace point they
> --
> 1.5.6.3
>
>
>
>
On Sat, 2009-04-04 at 11:42 -0400, Steven Rostedt wrote:
> On Sat, 4 Apr 2009, Tom Zanussi wrote:
> > On Fri, 2009-04-03 at 10:36 -0400, Steven Rostedt wrote:
> >
> > I'm guessing the problem is that CONFIG_EVENT_TRACER wasn't selected but
> > should have been, because those tracers all now export events
> > (trace_event_types.h, included by trace_export.c). I'm not sure this is
> > the right way to do it, but the patch below selects EVENT_TRACER if
> > TRACING is selected (a couple of the exported events belong to bprint
> > and print, which don't have a config option other than TRACING, so it
> > seems to belong there).
> >
> > Signed-off-by: Tom Zanussi <[email protected]>
> >
> > ---
> > kernel/trace/Kconfig | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > index 8a41360..a061746 100644
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
> > @@ -56,6 +56,7 @@ config TRACING
> > select TRACEPOINTS
> > select NOP_TRACER
> > select BINARY_PRINTF
> > + select EVENT_TRACER
>
> Yeah, we can do this.
>
> >
> > #
> > # Minimum requirements an architecture has to meet for us to
> > @@ -177,7 +178,7 @@ config CONTEXT_SWITCH_TRACER
> >
> > config EVENT_TRACER
> > bool "Trace various events in the kernel"
> > - select TRACING
> > + depends on TRACING
>
> This means we can only select EVENT_TRACER if something else has been
> selected. Can't we keep the "select TRACING" here.
>
Keeping 'select TRACING' here gives this error:
kernel/trace/Kconfig:53:error: found recursive dependency: TRACING ->
EVENT_TRACER -> TRACING
I'll have to play around with it some more...
Tom
> That way, we could just select EVENT_TRACER, but if anything other
> tracer is selected, we automatically get EVENT_TRACER.
>
> The logic would be, if you pick any tracer you get the EVENT_TRACER.
> But you can still just ask for the EVENT_TRACER with no other tracer.
> -- Steve
>
>
>
> > help
> > This tracer hooks to various trace points in the kernel
> > allowing the user to pick and choose which trace point they
> > --
> > 1.5.6.3
> >
> >
> >
> >
* Steven Rostedt <[email protected]> wrote:
> On Sat, 4 Apr 2009, Tom Zanussi wrote:
> > On Fri, 2009-04-03 at 10:36 -0400, Steven Rostedt wrote:
> >
> > I'm guessing the problem is that CONFIG_EVENT_TRACER wasn't selected but
> > should have been, because those tracers all now export events
> > (trace_event_types.h, included by trace_export.c). I'm not sure this is
> > the right way to do it, but the patch below selects EVENT_TRACER if
> > TRACING is selected (a couple of the exported events belong to bprint
> > and print, which don't have a config option other than TRACING, so it
> > seems to belong there).
> >
> > Signed-off-by: Tom Zanussi <[email protected]>
> >
> > ---
> > kernel/trace/Kconfig | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > index 8a41360..a061746 100644
> > --- a/kernel/trace/Kconfig
> > +++ b/kernel/trace/Kconfig
> > @@ -56,6 +56,7 @@ config TRACING
> > select TRACEPOINTS
> > select NOP_TRACER
> > select BINARY_PRINTF
> > + select EVENT_TRACER
>
> Yeah, we can do this.
Yeah - it has become more of a core facility thing, not a separate
plugin.
That's the long-term healthy life-cycle for certain tracing
functionality anyway: if it becomes so useful that all tracers want
to make use of it, it becomes part of the standard infrastructure.
Ingo