[lttng-dev] [for-next][PATCH 08/20] tracing: Warn if a tracepoint is not set via debugfs

[Steven Rostedt]

To sum up this thread, and get the signal vs noise ratio up.

On Wed, 12 Mar 2014 11:11:00 -0400
Steven Rostedt <rostedt at goodmis.org> 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 register a module load and unload handler
> to be able to see the tracepoints that exist in the module, and you can
> enable them then. When a module is unloaded, your module can do the
> accounting to record that, and the state of its tracepoints. 

This is my final proposal.

I'll add the patch that removes the tracepoint on failure along with
returning -ENODEV. That way, there will be no registered tracepoints
that do not exist.

I'll also make sure that on module unload, the tracepoints are disabled
for the module as well.

Then, you can simply add a module notifier that does the work that you
like, and save and restore the state of named tracepoints and enabled
them on module load. Just set the priority of the notifier to 1
so that it runs after the tracepoint notifier that adds the new
tracepoints to the system.

> 
> Looks like we can have it both ways. A way that works well for the
> kernel, and a way that works well for you. But your module will need to
> do the heavy work for what you want.
> 
> To me, a tracepoint should only be enabled when it exists. If it is
> enabled in module when the module is unloaded, then it should be
> removed after the module has left. If the module is loaded again, it is
> up to the user (or your module) to enable that tracepoint again.

I want to point out that LTTng should not be dictating the way the
kernel works, but it should be the other way around.

-- Steve