LTTng » LTTng-UST

For the part about refusing old tracepoint providers and old tracepoint modules, this is solved by having changed the API symbols for the registration functions in .so.1. This means the old applications/probes won't ever try to call the new API, even due to a weird build misconfiguration, because those have new names.

For the part where we want to ensure there are not lttng-ust nor lttng-ust-tracepoint libraries from .so.0 and .so.1 loaded in the same process, this gerrit review is an attempt at detecting this from .so.1:

https://review.lttng.org/c/lttng-ust/+/5616 Detect unsupported use of .so.0 and .so.1 libraries within same process

However, I am concerned about use-cases where a process is linked against multiple shared libraries, some of which have a dependency against liblttng-ust{,-tracepoint}.so.0, where it would not be practical to rebuild and deploy all libraries in locked-step.

In this kind of scenario, one possible approach we could consider is to provide a "stub" liblttng-ust{,-tracepoint}.so.0, which means the tracepoint instrumentation and tracepoint providers in the applications would try to register themselves to the stub, but would be ignored. I am not entirely sure this is practical nor something we really want to do though.

I am also unsure whether this is a scenario we really want to support.