Message-ID: <1499877773.3995.6.camel@tzanussi-mobl.amr.corp.intel.com>
Subject: Re: Dynamic tracepoints in 4.11.8-rt5
From: Tom Zanussi <tom.zanussi@linux.intel.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Thomas Gleixner <tglx@linutronix.de>, rostedt <rostedt@goodmis.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Michael Jeanson <mjeanson@efficios.com>
Date: Wed, 12 Jul 2017 11:42:53 -0500
In-Reply-To: <758517446.14680.1499875009807.JavaMail.zimbra@efficios.com>
References: <758517446.14680.1499875009807.JavaMail.zimbra@efficios.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1271
Lines: 44

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
>