[Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

DRBD_TRACE should depend on TRACING.
It's also possible that TRACEPOINTS should depend on TRACING.

arch/x86/built-in.o: In function `default_idle':
(.text+0x145a1): undefined reference to `__tracepoint_power_start'
arch/x86/built-in.o: In function `default_idle':
(.text+0x145d4): undefined reference to `__tracepoint_power_start'
arch/x86/built-in.o: In function `mwait_idle_with_hints':
(.text+0x1583d): undefined reference to `__tracepoint_power_start'
arch/x86/built-in.o: In function `mwait_idle_with_hints':
(.text+0x15870): undefined reference to `__tracepoint_power_start'
arch/x86/built-in.o: In function `mwait_idle':
process.c:(.text+0x15b92): undefined reference to `__tracepoint_power_start'
arch/x86/built-in.o:process.c:(.text+0x15bbe): more undefined references to `__tracepoint_power_start' follow
arch/x86/built-in.o: In function `poll_idle':
process.c:(.text+0x160bd): undefined reference to `__tracepoint_power_end'
process.c:(.text+0x160e9): undefined reference to `__tracepoint_power_end'
drivers/built-in.o: In function `cpuidle_idle_call':
cpuidle.c:(.text+0x517f16): undefined reference to `__tracepoint_power_end'
cpuidle.c:(.text+0x517f49): undefined reference to `__tracepoint_power_end'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/block/drbd/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20090925.orig/drivers/block/drbd/Kconfig
+++ linux-next-20090925/drivers/block/drbd/Kconfig
@@ -40,7 +40,7 @@ config BLK_DEV_DRBD
 
 config DRBD_TRACE
 	tristate "DRBD tracing"
-	depends on BLK_DEV_DRBD
+	depends on BLK_DEV_DRBD && TRACING
 	select TRACEPOINTS
 	default n
 	help

Re: [Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Philipp Reisner]

On Saturday 26 September 2009 01:03:04 Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> DRBD_TRACE should depend on TRACING.
> It's also possible that TRACEPOINTS should depend on TRACING.
>

Hi Randy,

I tried to figure out in which way that should be done. By looking
at "BLK_DEV_IO_TRACE" I got the impression that this should
be done by adding "select GENERIC_TRACER".

I will further examine this tomorrow. I just wanted to let you know
that this did not fall off the table...

-Phil

diff --git a/drivers/block/drbd/Kconfig b/drivers/block/drbd/Kconfig
index 4e6f90f..7b35287 100644
--- a/drivers/block/drbd/Kconfig
+++ b/drivers/block/drbd/Kconfig
@@ -7,7 +7,7 @@ comment "DRBD disabled because PROC_FS, INET or CONNECTOR not 
selected"

 config BLK_DEV_DRBD
        tristate "DRBD Distributed Replicated Block Device support"
-       depends on PROC_FS && INET && CONNECTOR
+       depends on BLOCK && PROC_FS && INET && CONNECTOR
        select LRU_CACHE
        default n
        help
@@ -42,6 +42,7 @@ config DRBD_TRACE
        tristate "DRBD tracing"
        depends on BLK_DEV_DRBD
        select TRACEPOINTS
+       select GENERIC_TRACER
        default n
        help
-- 
: Dipl-Ing Philipp Reisner
: LINBIT | Your Way to High Availability
: Tel: +43-1-8178292-50, Fax: +43-1-8178292-82
: http://www.linbit.com

DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.

Re: [Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Christoph Hellwig]

On Tue, Sep 29, 2009 at 05:32:50PM +0200, Philipp Reisner wrote:
> On Saturday 26 September 2009 01:03:04 Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> >
> > DRBD_TRACE should depend on TRACING.
> > It's also possible that TRACEPOINTS should depend on TRACING.
> >
> 
> Hi Randy,
> 
> I tried to figure out in which way that should be done. By looking
> at "BLK_DEV_IO_TRACE" I got the impression that this should
> be done by adding "select GENERIC_TRACER".

Neither really.  The only way of tracing that should be used is the
TRACE_EVENT macros, which compile away to nothing if tracing is
disabled, so no dependency is needed at all.

Re: [Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Lars Ellenberg]

On Tue, Sep 29, 2009 at 11:37:47AM -0400, Christoph Hellwig wrote:
> On Tue, Sep 29, 2009 at 05:32:50PM +0200, Philipp Reisner wrote:
> > On Saturday 26 September 2009 01:03:04 Randy Dunlap wrote:
> > > From: Randy Dunlap <randy.dunlap@oracle.com>
> > >
> > > DRBD_TRACE should depend on TRACING.
> > > It's also possible that TRACEPOINTS should depend on TRACING.
> > >
> > 
> > Hi Randy,
> > 
> > I tried to figure out in which way that should be done. By looking
> > at "BLK_DEV_IO_TRACE" I got the impression that this should
> > be done by adding "select GENERIC_TRACER".
> 
> Neither really.  The only way of tracing that should be used is the
> TRACE_EVENT macros, which compile away to nothing if tracing is
> disabled, so no dependency is needed at all.

TRACE_EVENT macros depend on, and use TRACE_POINTS.
And those trace points are what compiles away if !CONFIG_TRACEPOINTS, no?

kernel/trace/Kconfig says
# All tracer options should select GENERIC_TRACER. [...]

If one uses tracepoints without trace_events, they still compile away.

If using tracepoints directly, not using the (admittedly elegant)
trace-events macro system, is in fact not wanted anymore, then
Documentation/trace/* should be changed accordingly.

So what is the plan, going forward?

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

Re: [Drbd-dev] [PATCH -next] drbd: trace depends on TRACING

[Christoph Hellwig]

On Wed, Sep 30, 2009 at 10:02:21AM +0200, Lars Ellenberg wrote:
> TRACE_EVENT macros depend on, and use TRACE_POINTS.
> And those trace points are what compiles away if !CONFIG_TRACEPOINTS, no?

Everything compiles away when the right options are not selected.

> If using tracepoints directly, not using the (admittedly elegant)
> trace-events macro system, is in fact not wanted anymore, then
> Documentation/trace/* should be changed accordingly.

I could not find anything actively suggesting to use them.  And if you
look at current mainline there is in fact no user of raw tracepoints
left and none should be introduced.  If you add fancy new tracing it
might be a good idea to run it past Ingo and Steve, btw.

Ingo, now that we killed all raw tracepoints users, what do you think
about removing Documentation/trace/tracepoints.txt and
samples/tracepoints so that people have no easy way to use them?

Even better would be making their use really hard, which is not too easy
as they are used by TRACE_EVENT underneath.

> So what is the plan, going forward?

The plan is that all new tracing should use TRACE_EVENT.  If that
doesn't work for some reason bring it up with the tracing people
for discussion.