This is why there is a new

for_each_kernel_tracepoint()

interface, exported with EXPORT_SYMBOL_GPL. You can use it to iterate on each tracepoint defined within the core kernel, without having to rely on their symbol being exported.

The module tracepoints can be monitored using:

register_tracepoint_module_notifier()
unregister_tracepoint_module_notifier()

Please let me know if those interfaces do not fulfill your needs. FWIW, they are sufficient for LTTng to perform the same things it was doing in prior versions of the Linux kernel.

Thanks,

Mathieu

Mathieu, if I'm understanding the situation correctly the change in question took previously working userspace and broke it.  While providing a new for_each_kernel_tracepoint might be a solution going forward, I don't see how userspace that was working with the old API would continue to work.  It seems that a userspace code change would be required, and that userspace would then need to check the kernel version to figure out which API to use.

Is that an accurate assessment of the situation?  If so, that would seem to run afoul of the "don't break userspace" mantra that Linus so clearly pounds into people quite often...

Josh, it's not a userspace API being broken here, but kernel-space one.

OTOH, this aspect of the change was not noted in the LKML thread, so
came as a surprise.  There are no in-tree users for that iteration
function Mathieu wrote, and indeed git lttng-modules doesn't use
it either (yet), so it's hard to justify relying on it.

(Note that the EXPORT_TRACEPOINT_SYMBOL* mechanism is completely
mooted by the iteration function; it was just as moot before with
the named tracepoint registration.)

Ah, my mistake.  Thanks for the clarification.

Hi Frank,

I had the commit waiting in a dev branch until the tracepoint API change would make its way into the mainline kernel. I just pushed it to lttng-modules, see

commit 20591cf76d5dfd42d61a18bd494b40a70a04dd59
Author: Mathieu Desnoyers <mathieu.desnoyers>
Date:   Wed Mar 19 23:12:32 2014 -0400

    Adapt to 3.15 tracepoint API
    
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers>

I had tested those functions against this commit before submitting the tracepoint API change for inclusion.

Thanks,

Mathieu

After someone else posted patches to export the symbols upstream, the consensus seems to be that they don't need to be exported because there are no in-tree users and that external modules should use the new API.

Frank, do you want me to reassign this to systemtap to track the changes needed, or should I just close it out?

Thanks for checking, Josh.  Systemtap will adapt to these changes.
The other Josh has a prototype based on the lttng code Mathieu referred to above.

Mathieu, thanks for the shared code!  SystemTap 2.5 is fine now.

(I find it a bit silly that basically all tracepoint clients will need this kind of bookkeeping, but at least we're few in number...)

You're welcome!

The reasoning behind this change is that perf and ftrace (both in kernel) can use symbols to interact with tracepoints. It's easy for those, since they are built with the kernel and can modify the TRACE_EVENT macros to generate what they need.

So it's pretty much in the use-case where tracer modules (both in-tree and out of tree) want to interact with tracepoints in a way that allow enabling events even if the modules containing those events are not yet loaded that we need those hash tables. However, perf and ftrace don't care about this use-case.

Therefore, it seems like a good tradeoff to shrink the size of the kernel image for the common case (upstream perf and ftrace), and take a small space hit within tracer modules (but only when they are loaded).

Thanks,

Mathieu