nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
> , "Andi Kleen"
> Sent: Wednesday, March 12, 2014 11:10:53 PM
>
er" , "Andrew
> Morton" , "Johannes Berg"
> , "Linus Torvalds"
> , "Peter Zijlstra" ,
> "Thomas Gleixner" ,
> "Greg Kroah-Hartman" , "lttng-dev"
> , "Rusty Russell"
>
> Sent: Wednesday,
rg, "Ingo
> > Molnar" , "Frederic Weisbecker" ,
> > "Andrew Morton" ,
> > "Johannes Berg" , "Linus Torvalds"
> > , "Peter Zijlstra"
> > , "Thomas Gleixner" , "Greg
> > Kroah-Hartman"
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
> , "Andi Kleen"
> Sent: Wednesday, March 12, 2014 8:49:07 PM
> S
On Wed, 12 Mar 2014 19:51:01 + (UTC)
Mathieu Desnoyers 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
__tracepoi
ew Morton" ,
> "Johannes Berg" , "Linus Torvalds"
> , "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
> , "Andi Kleen"
> Sent: Wednesday, March 12,
> So I understand that you wish to banish tracepoints from static inline
> functions within headers to ensure they only appear within a single module.
> This seems to be a step backward, but let's assume we stick to that rule.
> Then how do you envision dealing with Link-Time Optimisations (LTO) ?
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
>
> Sent: Wednesday, March 12, 2014 3:30:06 PM
> Subject: Re: [for-next][PATCH
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
>
> Sent: Wednesday, March 12, 2014 2:58:02 PM
> Subject: Re: [for-next][PA
On Wed, 12 Mar 2014 14:58:02 -0400
Steven Rostedt wrote:
>
> Two modules should not have the same name. Is there any duplicate
> tracepoints you are aware of. Namespace collisions in tracepoints
> should be avoided, as that would cause people to trace things they did
> not intend on tracing.
>
On Wed, 12 Mar 2014 18:47:15 + (UTC)
Mathieu Desnoyers wrote:
> > On module unload, the events are destroyed.
>
> Isn't trace_event.c responsible for dealing with tracepoint probes rather
> than call sites ? This is quite different. A tracepoint probe "foo" is only
> located within a single
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
>
> Sent: Wednesday, March 12, 2014 1:50:59 PM
> Subject: Re: [for-next][P
On Wed, 12 Mar 2014 16:40:51 + (UTC)
Mathieu Desnoyers wrote:
> > Please tell me one in-tree user that will be impacted?
>
> I'm talking about all users of tracepoints, all in tree and out of tree
> users. We need the design and API for tracepoint to stay sound, and for that
> we need to st
On Wed, 12 Mar 2014 16:39:55 + (UTC)
Mathieu Desnoyers wrote:
> > Are you telling me it's not possible to delete the entire probe?
>
> The ownership flow is the following:
>
> 1) Tracer creates name, probe, data objects. The probe can be typically
>code within a probe provider module,
; Mathieu Desnoyers wrote:
>
> > - Original Message -
> > > From: "Steven Rostedt"
> > > To: "Mathieu Desnoyers"
> > > Cc: "Frank Ch. Eigler" , linux-kernel@vger.kernel.org,
> > > "Ingo Molnar" , "
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
>
> Sent: Wednesday, March 12, 2014 12:18:13 PM
> Subject: Re: [for-next][
uot; , "Frederic
> > Weisbecker" , "Andrew Morton"
> > , "Johannes Berg"
> > , "Linus Torvalds"
> > , "Peter Zijlstra"
> > , "Thomas Gleixner" , "Greg
> > Kroah-Hartman" ,
> > &qu
nnes Berg"
> , "Linus Torvalds" ,
> "Peter Zijlstra"
> , "Thomas Gleixner" , "Greg
> Kroah-Hartman" ,
> "lttng-dev" , "Rusty Russell"
>
> Sent: Wednesday, March 12, 2014 11:46:11 AM
> Subject: Re: [for-next]
To sum up this thread, and get the signal vs noise ratio up.
On Wed, 12 Mar 2014 11:11:00 -0400
Steven Rostedt wrote:
> The solution I like the most that I believe will work for both of us,
> is to to move this magic "enable tracepoint in the future" to your
> LTTng module. Have your module re
uot; , "Frederic
> > Weisbecker" , "Andrew Morton"
> > , "Johannes Berg"
> >
> > Sent: Tuesday, March 11, 2014 3:13:57 PM
> > Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not
> > set via debugfs
> >
Berg"
>
> Sent: Tuesday, March 11, 2014 3:13:57 PM
> Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set
> via debugfs
>
For those just added in CC, https://lkml.org/lkml/2014/3/11/431 provides the
missing context. The discussion is about adding mod
On Tue, 11 Mar 2014 17:34:23 + (UTC)
Mathieu Desnoyers wrote:
> > Who can load modules not as root?? That is utterly broken. As once you
> > can load a module, YOU ARE ROOT.
>
> udevd runs as root, and listens to events such as USB hotplug, and loads
> modules
> in the back of users. The u
annes Berg"
>
> Sent: Tuesday, March 11, 2014 11:40:23 AM
> Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set
> via debugfs
>
> On Tue, 11 Mar 2014 15:06:22 + (UTC)
> Mathieu Desnoyers wrote:
>
>
> > Let's step back and look
On Tue, 11 Mar 2014 15:06:22 + (UTC)
Mathieu Desnoyers wrote:
> Let's step back and look at the overall picture here, along with the
> possible solutions that are available so far.
>
> My intent is to let end users specify "I want to trace this specific
> tracepoint" from the tracer interfa
t;Johannes Berg"
> Sent: Tuesday, March 11, 2014 10:26:50 AM
> Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set
> via debugfs
>
> Hi, Steven -
>
> > > So it is a deferred-activation kind of call, with no way of knowing
> > > when
On Tue, 11 Mar 2014 04:08:27 + (UTC)
Mathieu Desnoyers wrote:
> > That's my argument.
>
> So basically, all we'd have to do in LTTng is to add a hash table tracking the
> tracepoint probes which are registered, but for which there are no
> tracepoint call sites. Whenever registration of a
Hi, Steven -
> > So it is a deferred-activation kind of call, with no way of knowing
> > when or if the tracepoints will start coming in. Why is that
> > supported at all, considering that clients could monitor modules
> > coming & going via the module_notifier chain, and update registration
> >
nnes Berg"
> Sent: Monday, March 10, 2014 10:58:20 PM
> Subject: Re: [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set
> via debugfs
>
> On Mon, 10 Mar 2014 22:41:31 -0400
> f...@redhat.com (Frank Ch. Eigler) wrote:
>
> >
> > Hi -
&
On Mon, 10 Mar 2014 22:41:31 -0400
f...@redhat.com (Frank Ch. Eigler) wrote:
>
> Hi -
>
>
> >> From: Steven Rostedt
> >>
> >> Tracepoints were made to allow enabling a tracepoint in a module before
> >> that
> >> module was loaded. When a tracepoint is enabled and it does not exist, the
> >>
Hi -
>> From: Steven Rostedt
>>
>> Tracepoints were made to allow enabling a tracepoint in a module before that
>> module was loaded. When a tracepoint is enabled and it does not exist, the
>> name is stored and will be enabled when the tracepoint is created.
>>
>> The problem with this appro
- Original Message -
> From: "Steven Rostedt"
> To: "Mathieu Desnoyers"
> Cc: linux-kernel@vger.kernel.org, "Ingo Molnar" , "Frederic
> Weisbecker" ,
> "Andrew Morton" , "Johannes Berg"
>
> Sent: Monday,
On Mon, 10 Mar 2014 20:01:34 + (UTC)
Mathieu Desnoyers wrote:
> > mutex_lock(&tracepoints_mutex);
> > old = tracepoint_add_probe(name, probe, data);
> > @@ -388,9 +393,13 @@ int tracepoint_probe_register(const char *name, void
> > *probe, void *data)
> > return PTR_ERR(ol
- Original Message -
> From: "Steven Rostedt"
> To: linux-kernel@vger.kernel.org
> Cc: "Ingo Molnar" , "Frederic Weisbecker"
> , "Andrew Morton"
> , "Mathieu Desnoyers"
> , "Johannes Berg"
>
> Sent: Fri
From: Steven Rostedt
Tracepoints were made to allow enabling a tracepoint in a module before that
module was loaded. When a tracepoint is enabled and it does not exist, the
name is stored and will be enabled when the tracepoint is created.
The problem with this approach is that when a tracepoint
34 matches
Mail list logo
