To sum up this thread, and get the signal vs noise ratio up. On Wed, 12 Mar 2014 11:11:00 -0400 Steven Rostedt <rost...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
