Hello,
I already started a thread over at xenomai.org [1], but I guess its
more efficient to ask here aswell.
The basic concept is that xenomai thread run *below* Linux (threads
and irg handlers), which means that xenomai threads must not use any
linux services like the futex syscall or socket com
Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka :
>
> On 22.11.19 16:42, Mathieu Desnoyers wrote:
> > - On Nov 22, 2019, at 4:14 AM, Norbert Lange nolang...@gmail.com wrote:
> >
> >> Hello,
> >>
> >> I already started a thread over at xenomai
>
> LTTng-UST prepares the ring buffers from lttng-ust's "listener" thread,
> which is injected into the process by a lttng-ust constructor.
>
> What you will care about is how the tracepoint call-site (within a Xenomai
> thread) interacts with the ring buffers.
>
> The "default" setup for lttng-us
Am Fr., 22. Nov. 2019 um 18:52 Uhr schrieb Jan Kiszka :
>
> On 22.11.19 18:44, Norbert Lange wrote:
> > Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka
> > :
> >>
> >> On 22.11.19 16:42, Mathieu Desnoyers wrote:
> >>> - On Nov 22, 201
I still would like to propose having a compile time "off switch",
cant see how this would work with preloaded libraries for one
(lttng itself whips with multiple)
Cant tell for sure now, but a setup where "bulletproof Xenomai"
libraries are used seems to better than special setup magic.
If you hav
Am Fr., 22. Nov. 2019 um 20:00 Uhr schrieb Mathieu Desnoyers
:
>
> - On Nov 22, 2019, at 12:44 PM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Fr., 22. Nov. 2019 um 16:52 Uhr schrieb Jan Kiszka
> > :
> >>
> >> On
Am Fr., 22. Nov. 2019 um 20:03 Uhr schrieb Mathieu Desnoyers
:
>
> - On Nov 22, 2019, at 12:55 PM, Norbert Lange nolang...@gmail.com wrote:
>
> >>
> >> LTTng-UST prepares the ring buffers from lttng-ust's "listener" thread,
> >> which is i
> >> >> > Another thing to make sure is to have a glibc and Linux kernel which
> >> >> > perform
> >> >> > clock_gettime() as vDSO for the monotonic clock, because you don't
> >> >> > want a
> >> >> > system call there. If that does not work for you, you can
> >> >> > alternatively
> >> >> > imp
> >> liburcu has configure options allow forcing the usage of this syscall
> >> but not disabling it, which likely is necessary for Xenomai.
> >
> > I suspect what you'd need there is a way to allow a process to tell
> > liburcu-bp (or liburcu) to always use the fall-back mechan
Hello,
The flag -fno-common will cause multiple duplicate symbols, gcc 10
will use this as default, so it will only be a matter of time till you
get some more FTB reports ;)
Norbert
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttn
Hello,
since lttng would make for a decent logger, is it possible to create a
own tracepoint provider and channel and acess it in the very same
process thats traced?
the log entries would need to be accessible directly to support some
existing schemes for manipulating (interpolating to a different
tly, to serialize the events to stdout/stderr from the
> application itself.
>
> Maybe I misunderstood your question. Let me know.
>
> Jérémie
>
> On 6 August 2018 at 18:42, Norbert Lange wrote:
> > Hello,
> >
> > since lttng would make for a decent logger, is it
Hello,
I finally got some time digging into Lttng (using it on Xenomai, see
[1] for historic reference).
Since we have a hard realtime system, I chosen to use dynamic probes.
That means only
liblttng-ust-tracepoint.so wil get pulled into the process (it its
available), no threads are spawned, etc
Hello,
Several context fields will cause a syscall atleast the first time a
tracepoint is
recorded. For example all of the following:
`lttng add-context -c chan --userspace --type=vpid --type=vtid --type=procname`
Each of them seems cached in TLS however, and most should never change
after start
Try to use vsnprintf with a 512 Byte buffer on the Stack,
if that fails allocate a larger one.
Signed-off-by: Norbert Lange
---
liblttng-ust/tracef.c | 13 ++---
liblttng-ust/tracelog.c | 12 +---
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/liblttng-ust
Am Do., 20. Mai 2021 um 09:58 Uhr schrieb MONTET Julien via lttng-dev
:
>
> Hi the developers !
>
> CONTEXT
> I am currently working on a Raspberry pi 3B with Xenomai and LTTng tools.
> Raspbian 10.9 Buster - kernel 4.19.85
> uname -a : Linux raspberrypi 4.19.85-v7+ #5 SMP PREEMPT Wed May 12 10:13:
Am Do., 20. Mai 2021 um 10:28 Uhr schrieb MONTET Julien
:
>
> Hi Norbert,
>
> Thank you for your answer !
>
> Yes, I am using a Xenomai cobalt - xenomai is 3.1
> cat /proc/xenomai/version => 3.1
>
> After the installation, I tested "test tools" in /proc/xenomai/ and it worked
> nice.
Just asked t
Instead of creating functions for each loglevel, simply pass the
callback as argument.
Further pack all preprocessor information into a struct that
the compiler already can prepare.
Signed-off-by: Norbert Lange
---
include/lttng/tracelog.h | 49 +
src/lib/lttng-ust/tracelog.c
rintf.
This will result in the function never becoming inlined,
thus the helper function was manually "inlined".
Signed-off-by: Norbert Lange
---
src/common/tracer.h | 2 +
src/lib/lttng-ust/tracef.c | 83 -
src/lib/lttng-ust/tracelog.c | 90
e approach.
>
> Can we move the hardcoded "512" to a #define within src/common/tracer.h ?
>
> Thanks,
>
> Mathieu
>
> >
> > Signed-off-by: Norbert Lange
> > ---
> > liblttng-ust/tracef.c | 13 ++---
> > liblttng-ust/tracelog.c | 12
Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 19, 2021, at 8:11 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
> > Hello,
> >
> > Several context fields will cause a syscall atleast the first time a
> > tracepoint is
> > recorded. For example all of the following:
Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 8:46 AM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Mi., 19. Mai 2021 um 20:52 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> - On May 19, 2021, at 8:11
Am Do., 20. Mai 2021 um 15:33 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 8:20 AM, Norbert Lange nolang...@gmail.com wrote:
>
> > This patch was intended for 2.12, no src/common/tracer.h there.
>
> You should post feature patches against the master branch.
Hello,
many tests fail to build, apparently because transitive dependencies
are not found.
I managed to patch out building the test sub-directory, at which
points the errors are gone,
I dont know how to fix it with automake, seems like
/tmp/ZBuild/build/lttng-libust-2.13.0-rc2/src/lib/lttng-ust/.l
Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 8:18 AM, lttng-dev lttng-dev@lists.lttng.org wrote:
>
> > Instead of creating functions for each loglevel, simply pass the
> > callback as argument.
> >
> > Further pack all preprocessor information into a s
Am Do., 20. Mai 2021 um 17:09 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 9:56 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On May 20, 2021, at 9:54 AM, lttng-dev lttng-dev@lists.lttng.org
> > wrote:
> >
> >> - On May 20, 2021, at 5:11 AM, lttng-
Am Do., 20. Mai 2021 um 17:21 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 10:57 AM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Do., 20. Mai 2021 um 16:19 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> - On May 20, 2021, at 8:18
Am Do., 20. Mai 2021 um 16:37 Uhr schrieb Michael Jeanson
:
>
> On 2021-05-20 9:52 a.m., Norbert Lange via lttng-dev wrote:
> > Hello,
> >
> > many tests fail to build, apparently because transitive dependencies
> > are not found.
> > I managed to patch out
Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 11:54 AM, Norbert Lange nolang...@gmail.com wrote:
> [...]
>
> >> What prevents you from linking against lttng-ust.so again ?
> >
> > I did not poke around enough with L
Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers
:
>
>
>
> - On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> - On May 20, 2021, a
Am Fr., 21. Mai 2021 um 12:13 Uhr schrieb MONTET Julien
:
>
> Hello Mathieu, Norbert and Jan,
>
> Thank you for all of your explainations and the overview of the system.
> No I didn't change the ipipe patch for the vDSO, I may try this.
> If I have correctly understood, this patch prevents Cobalt f
Am Do., 20. Mai 2021 um 19:18 Uhr schrieb Mathieu Desnoyers
:
>
>
>
> - On May 20, 2021, at 12:51 PM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Do., 20. Mai 2021 um 18:25 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> - On May 20, 2021, a
rintf.
The implementation was moved to a separate file,
used by both tracef.c and tracelog.c.
Signed-off-by: Norbert Lange
---
src/common/tracer.h | 2 +
src/lib/lttng-ust-tracepoint/tracef.c | 32 ++-
.../lttng-ust-tracepoint/tracelog-internal.h | 83
Am Di., 25. Mai 2021 um 15:44 Uhr schrieb Norbert Lange :
>
> Support two common cases, one being that the resulting message is
> small enough to fit into a on-stack buffer.
> The seconds being the common 'printf("%s", "Message")' scheme.
>
> Unfortu
Hello,
Some old topic, see
https://lists.lttng.org/pipermail/lttng-dev/2019-November/029411.html.
(I actually thought this was solved meanwhile).
With lttng 2.13 liburcu is replicated in lttng-ust so my old custom
hack aint helping.
Aside from another crude hack, I thought about doing this:
ext
n function.
Useful would be either try to find the library in /usr/local/lib or
use '/usr/local/lib/libmyservice-tracepoints.so''
instead of lttng-ust-tracepoint (both have (dis)advantages).
At any rate, I would welcome some customization macro.
For illustration the current hack-arou
racepoint.so could be loaded later and not
pulled in by the tracepoint stubs,
but I understand that this is complicated.
Any good reason not to provide some customization point like
LTTNG_TRACEPOINT_PROBE_DLOPEN
for the stuff you locally include into your build?
Would meet me half-way ;)
Norbert
Hello Mathieu,
Am Do., 20. Mai 2021 um 16:16 Uhr schrieb Mathieu Desnoyers
:
>
> - On May 20, 2021, at 9:42 AM, Norbert Lange nolang...@gmail.com wrote:
>
> > Am Do., 20. Mai 2021 um 15:28 Uhr schrieb Mathieu Desnoyers
> > :
> >>
> >> ----- On May 20,
rintf.
The implementation was moved to a separate file,
used by both tracef.c and tracelog.c.
Signed-off-by: Norbert Lange
---
v2:
- move define into src/common/tracer.h
see https://lists.lttng.org/pipermail/lttng-dev/2021-May/029977.html
- moved macro magic into common tracelog-internal.h
Eagerly register the thread, and avoid taking mutex during the
first tracepoint.
Signed-off-by: Norbert Lange
---
src/lib/lttng-ust/lttng-ust-comm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/lib/lttng-ust/lttng-ust-comm.c
b/src/lib/lttng-ust/lttng-ust-comm.c
index ba0bd985
es. Tracepoints can then avoid
systemcalls.
Signed-off-by: Norbert Lange
---
* see
https://lore.kernel.org/all/CADYdroN3=pae66crtsvt9ahe4t+bt61-tvhfkcuwzykhhuy...@mail.gmail.com/
* Will update docs after review, and do some more tests
during the week
---
src/lib/lttng-ust/lttng-context-cgroup
Am Di., 19. Juli 2022 um 21:39 Uhr schrieb Mathieu Desnoyers
:
>
> - On Jul 18, 2022, at 5:59 PM, Norbert Lange via lttng-dev
> lttng-dev@lists.lttng.org wrote:
>
> > Modify all relevant *_alloc_tls functions so that they take an
> > argument for 'init'
From: Norbert Lange
Support two common cases, one being that the resulting message is
small enough to fit into a on-stack buffer.
The seconds being the common 'printf("%s", "Message")' scheme.
Unfortunately, iterating a va_list is destructive,
so it has to be copie
From: Norbert Lange
Eagerly register the thread, and avoid taking mutex during the
first tracepoint.
Signed-off-by: Norbert Lange
Acked-by: Mathieu Desnoyers
---
src/lib/lttng-ust/lttng-ust-comm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/lib/lttng-ust/lttng-ust-comm.c
b/src
From: Norbert Lange
Modify all relevant *_alloc_tls functions so that they take
flags for 'init'. Rename them to init_thread for consistency.
So far define one flag LTTNG_UST_INIT_THREAD_CONTEXT_CACHE,
this will warm up cached values so less is done during
the first tracepoint.
Th
Am Mo., 1. Aug. 2022 um 16:35 Uhr schrieb Norbert Lange :
>
> From: Norbert Lange
>
> Support two common cases, one being that the resulting message is
> small enough to fit into a on-stack buffer.
> The seconds being the common 'printf("%s", "Message&quo
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 t
Am Di., 17. Juni 2025 um 16:50 Uhr schrieb Kienan Stewart
:
>
> Hi Norbert,
>
> On 6/17/25 10:15 AM, Norbert Lange via lttng-dev wrote:
> > /tmp/dev_develop_libxml2/usr/include/libxml2/libxml/encoding.h:173:7:
> > note: declared here
> >173 |
/tmp/dev_develop_libxml2/usr/include/libxml2/libxml/encoding.h:173:7:
note: declared here
173 | } input XML_DEPRECATED_MEMBER;
| ^
../../../src/common/config/session-config.cpp:297:75: error: no match
for call to '(_xmlCharEncodingHandler::) (xmlChar*&,
int*, const xmlChar*, i
Am Fr., 10. Dez. 2021 um 23:43 Uhr schrieb Norbert Lange :
>
> Am Di., 5. Okt. 2021 um 20:28 Uhr schrieb Mathieu Desnoyers
> :
> >
> > - On Jul 15, 2021, at 7:21 AM, lttng-dev lttng-dev@lists.lttng.org
> > wrote:
> >
> > > Hello,
> > >
>
Am Di., 17. Juni 2025 um 16:13 Uhr schrieb Kienan Stewart via
lttng-dev :
>
> Hi Norbert,
>
> could you describe more about the context of the system you were
> building on, and which version of babeltrace you had installed?
>
> thanks,
> kienan
>
> On 6/17/25 6:54 A
Hello,
I had to add babeltrace2_CFLAGS="-DA" babeltrace2_LIBS="-lm" to the
configure line
to be able to build.
There should be a --without-babeltrace2 switch and possible automatic detection.
Regards, Norbert
Hello,
enum communication_state exists twice with already diverging definitions.
I am not sure if its a functional issue now, but this sound like it
can cause fun bughunts in the future.
(enabling lto helps finding that kinda stuff)
../../../../src/lib/lttng-ctl/clear.cpp:26:6: warning: type
'co
Hello David,
You cant fully isolate a core in Linux, there are some timekeeping
functions that will always run (Linux needs some basic runtime
accounting).
The things you can do is avoiding IRQ handlers and "lazy" subsystems
that depend on background updates via timer or IPI. You already do
this
anks,
> 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 w
55 matches
Mail list logo
