[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1499877773.3995.6.camel@tzanussi-mobl.amr.corp.intel.com>
Date: Wed, 12 Jul 2017 11:42:53 -0500
From: Tom Zanussi <tom.zanussi@...ux.intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Thomas Gleixner <tglx@...utronix.de>,
rostedt <rostedt@...dmis.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Michael Jeanson <mjeanson@...icios.com>
Subject: Re: Dynamic tracepoints in 4.11.8-rt5
Hi Mathieu,
On Wed, 2017-07-12 at 15:56 +0000, Mathieu Desnoyers wrote:
> Hi Tom,
>
> I notice this commit appears in linux-rt-devel 4.11.8-rt5
> (and it is not in upstream Linux):
>
> 003100371 tracing: Add support for dynamic tracepoints
>
> It adds a "bool dynamic" argument to tracepoint_probe_unregister.
>
> I'm trying to figure out why this change is introduced as a new API
> "dynamic_tracepoint_probe_register()" and by adding a boolean
> to tracepoint_probe_unregister().
>
> Allowing the user of register API to mixup between dynamic
> and non-dynamic boolean values for the same tracepoint instance
> seems fragile.
>
> Given that the "dynamic" nature of this new kind of tracepoint
> appears to be associated with the tracepoint instance
> (struct tracepoint), why can't we simply add a "bool dynamic"
> field to struct tracepoint, so we can deal with this internally
> within tracepoint.c without exposing this detail in the register
> API ?
>
Yeah, I think that should work - I'm working on an update to these
patches and will make that change.
Thanks,
Tom
> This would also take care of currently diverging module APIs for the
> GPL-exported symbol tracepoint_unregister() between Linux upstream
> and linux-rt.
>
> Thanks,
>
> Mathieu
>
Powered by blists - more mailing lists