Hi Norbert,
On 6/23/25 3:04 PM, Norbert Lange wrote:
I dont want to use anything else, I just want to add instrumentation
for dynamically loaded tracepoints that does next to nothing if not
activated (see [1]).
liblttng-ust-ctl is not even ABI compatible between 2.13 and 2.14
(different soname), so that's pretty useless since it already binds to
either 2.13 or 2.14 at compile-time.
I hadn't considered that the soname for liblttng-ust-ctl had changed
between versions. Thanks for pointing that out.
[1] - https://lists.lttng.org/pipermail/lttng-dev/2021-May/030004.html
Norbert
Then, it sounds to me like there's not a way to do the check you're
asking for with the public API at this time.
If there's a way you would like to address it that matches your needs,
you're welcome to propose a patch to introduce it.
thanks,
kienan
Am Mo., 23. Juni 2025 um 16:21 Uhr schrieb Kienan Stewart
<kstew...@efficios.com>:
Hi Norbert,
If you link to liblttng-ust-ctl, you can use `lttng_ust_ctl_get_version`.
thanks,
kienan
On 6/18/25 11:22 AM, Norbert Lange via lttng-dev wrote:
Hi,
there are some substantial changes in 2.14.0 that afffect how/if
tracing is possible.
For ex. c246521ddcba1d1d28cfa0482aa500b9122e7264 allows doing more work upfront
by calling lttng_ust_init_thread().
With 2.13.x the same code will instead do various syscalls or
allocations during the first tracepoints, violating realtime
constraints and possible abort the process.
I miss an easy method to inspect the Lttng UST Version for checks or
workarounds.
There is the lttng_ust_loaded variable that could be abused to carry
an packed version instead of 1. (Of course that could always cause
fallout)
Regards, Norbert
