From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Berg <johannes.berg@intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
lttng-dev <lttng-dev@lists.lttng.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs
Date: Thu, 13 Mar 2014 15:24:46 +0000 (UTC) [thread overview]
Message-ID: <970465661.2809.1394724286739.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <209084517.2310.1394680253793.JavaMail.zimbra@efficios.com>
----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "Steven Rostedt" <rostedt@goodmis.org>
> Cc: "Frank Ch. Eigler" <fche@redhat.com>, linux-kernel@vger.kernel.org, "Ingo Molnar" <mingo@kernel.org>, "Frederic
> Weisbecker" <fweisbec@gmail.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Johannes Berg"
> <johannes.berg@intel.com>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Peter Zijlstra"
> <peterz@infradead.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
> "lttng-dev" <lttng-dev@lists.lttng.org>, "Rusty Russell" <rusty@rustcorp.com.au>, "Andi Kleen" <andi@firstfloor.org>
> Sent: Wednesday, March 12, 2014 11:10:53 PM
> Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs
>
> ----- Original Message -----
> > From: "Steven Rostedt" <rostedt@goodmis.org>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> > Cc: "Frank Ch. Eigler" <fche@redhat.com>, linux-kernel@vger.kernel.org,
> > "Ingo Molnar" <mingo@kernel.org>, "Frederic
> > Weisbecker" <fweisbec@gmail.com>, "Andrew Morton"
> > <akpm@linux-foundation.org>, "Johannes Berg"
> > <johannes.berg@intel.com>, "Linus Torvalds"
> > <torvalds@linux-foundation.org>, "Peter Zijlstra"
> > <peterz@infradead.org>, "Thomas Gleixner" <tglx@linutronix.de>, "Greg
> > Kroah-Hartman" <gregkh@linuxfoundation.org>,
> > "lttng-dev" <lttng-dev@lists.lttng.org>, "Rusty Russell"
> > <rusty@rustcorp.com.au>, "Andi Kleen" <andi@firstfloor.org>
> > Sent: Wednesday, March 12, 2014 8:49:07 PM
> > Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not
> > set via debugfs
> >
> > On Wed, 12 Mar 2014 19:51:01 +0000 (UTC)
> > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> >
> > > This only leaves tracepoints in header files and the impact of LTO as
> > > requirements for having tracepoint callsites with the same name across
> > > modules.
> >
> > The only thing that needs to be unique is the struct tracepoint
> > __tracepoint_##name. There should not be any duplicates of those. I
> > can't see how the LTO would duplicate a data structure without screwing
> > everything (not just tracepoints) up.
> >
> > We can still have more than one trace_##name() called, as that is
> > handled by the static key.
>
> Hrm, I seem to have mixed up the concerns regarding compiler
> optimisations between the static keys with those related to tracepoints
> (including that their predecessors "kernel markers" worked more like
> static keys than tracepoint). I did work in both area pretty much at the
> same time back in 2007-2008.
>
> Having gotten my head back up straight, I now see the point in your
> proposal. Thanks for bearing with me.
>
> Even if we ever want to have tracepoints within header files, as long
> as we have the DECLARE_TRACE() within the header, and a DEFINE_TRACE()
> in one location in the loaded kernel image (or a loaded module we depend
> on), it should be possible too. All tracepoint.c cares about is the site
> defined by DEFINE_TRACE().
I just prepared a patch implementing your idea. I will post it as RFC very
soon. The callers will still need to be adapted, so this is just to show
the tracepoint.c/h modifications.
Thanks!
Mathieu
>
> >
> > Note, I'm scrambling to get ready for my trip tomorrow. Thus, I'm not
> > as much at the computer. I may work on some patches in my 6 hour
> > layover though.
>
> Allright. Have a good trip!
>
> Thanks,
>
> Mathieu
>
> >
> > -- Steve
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2014-03-13 15:24 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 15:09 [for-next][PATCH 00/20] tracing: linux-next updates Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 01/20] ftrace/x86: Run a sync after fixup on failure Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 02/20] ftrace/x86: One more missing sync after fixup of function modification failure Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 03/20] tracepoint: Do not waste memory on mods with no tracepoints Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 04/20] ftrace/x86: Have ftrace_write() return -EPERM and clean up callers Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 05/20] tracing: Move raw output code from macro to standalone function Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 06/20] tracing: Move event storage for array " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 07/20] tracing: Use helper functions in event assignment to shrink macro size Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs Steven Rostedt
2014-03-10 20:01 ` Mathieu Desnoyers
2014-03-10 20:19 ` Steven Rostedt
2014-03-10 20:55 ` Mathieu Desnoyers
2014-03-11 2:41 ` Frank Ch. Eigler
2014-03-11 2:58 ` Steven Rostedt
2014-03-11 4:08 ` Mathieu Desnoyers
2014-03-11 14:46 ` Steven Rostedt
2014-03-11 14:26 ` Frank Ch. Eigler
2014-03-11 15:06 ` Mathieu Desnoyers
2014-03-11 15:40 ` Steven Rostedt
2014-03-11 17:34 ` Mathieu Desnoyers
2014-03-11 19:13 ` Steven Rostedt
2014-03-12 14:24 ` Mathieu Desnoyers
2014-03-12 15:11 ` Steven Rostedt
2014-03-12 15:46 ` Steven Rostedt
2014-03-12 16:05 ` Mathieu Desnoyers
2014-03-12 16:18 ` Steven Rostedt
2014-03-12 16:39 ` Mathieu Desnoyers
2014-03-12 17:50 ` Steven Rostedt
2014-03-12 18:47 ` Mathieu Desnoyers
2014-03-12 18:58 ` Steven Rostedt
2014-03-12 19:30 ` Steven Rostedt
2014-03-12 19:58 ` Mathieu Desnoyers
2014-03-12 19:51 ` Mathieu Desnoyers
2014-03-12 20:35 ` Andi Kleen
2014-03-12 20:47 ` Mathieu Desnoyers
2014-03-13 3:15 ` Andi Kleen
2014-03-13 3:21 ` Mathieu Desnoyers
2014-03-13 0:49 ` Steven Rostedt
2014-03-13 3:10 ` Mathieu Desnoyers
2014-03-13 15:24 ` Mathieu Desnoyers [this message]
2014-03-12 16:40 ` Mathieu Desnoyers
2014-03-12 18:02 ` Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 09/20] tracing: Fix event header writeback.h to include tracepoint.h Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 10/20] tracing: Fix event header migrate.h " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 11/20] tracing/module: Replace include of tracepoint.h with jump_label.h in module.h Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 12/20] tracing: Correctly expand len expressions from __dynamic_array macro Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 13/20] tracing: Evaluate len expression only once in " Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 14/20] ftrace: Cleanup of global variables ftrace_new_pgs and ftrace_update_cnt Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 15/20] ftrace: Inline the code from ftrace_dyn_table_alloc() Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 16/20] ftrace: Pass retval through return in ftrace_dyn_arch_init() Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 17/20] ftrace: Do not pass data to ftrace_dyn_arch_init Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 18/20] ftrace: Remove freelist from struct dyn_ftrace Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 19/20] ftrace: Warn on error when modifying ftrace function Steven Rostedt
2014-03-07 15:09 ` [for-next][PATCH 20/20] ftrace/x86: BUG when ftrace recovery fails Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=970465661.2809.1394724286739.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lttng-dev@lists.lttng.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox