[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090930160001.GA3765@infradead.org>
Date: Wed, 30 Sep 2009 12:00:01 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Philipp Reisner <philipp.reisner@...bit.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
akpm <akpm@...ux-foundation.org>, drbd-dev@...ts.linbit.com,
mingo@...e.hu, rostedt@...dmis.org
Subject: Re: [Drbd-dev] [PATCH -next] drbd: trace depends on TRACING
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists