[lttng-dev] introduction & usage of LTTNG in machinekit
mail17 at mah.priv.at
Sun Mar 29 11:17:27 EDT 2015
> Am 29.03.2015 um 16:31 schrieb Michel Dagenais <michel.dagenais at polymtl.ca>:
>> - is there a complete example out-of-tree kernel module instrumented for
>> LTTng? I worked through Steve Rostedt's sillymod
>> (http://lwn.net/Articles/379903 ff) but am fuzzy on "Adding the LTTng
>> adaptation layer" - is the example from the manual available in toto
> A few people in my group have done so. I will check on Monday to get sample code for you.
on re-reading, I am almost there, but I'd appreciate an example anyway
>> - much of the machinekit RT code (HAL library and components) can be compiled
>> as userland shared objects (Posix, RT-PREEMPP, Xenomai threads) or kernel
>> modules (RTAI, and the deprecated Xenomai kernel API), sitting ontop of an
>> abstracted realtime API ("RTAPI"). Ideally the tracepoints would work
>> unchanged except for the different context. The manual naturally assumes an
>> either-or context. Am I out on a limb here ;-? How would I bring in the
>> tracepoint definitions in a kernel context - as a separate module maybe or
>> linked into each using module?
> I dont believe that we have examples of code that compile in both kernel and UST contexts. This can certainly be handled with conditional compilation.
right, I need to wrap my head around the maze of #defines and #includes ;) but it looks possible
>> - we cannot assume that lttng is available when building machinekit packages
>> at least for now, meaning we likely need shim macro definitions and possibly
>> fake header files to adjust for the lacking lttng files. Any examples I can
> MariaDB and others can target different tracers (LTTng, DTrace, none)... Again, I will try to get you good sample code early next week.
I thought I might not be the first one to do this
semi-related because I was bitten by it: the Xenomai configs referenced here: http://www.xenomai.org/pipermail/xenomai/2013-January/027272.html turn CONFIG_FTRACE off, citing performance reasons. I think we'll turn it back on in our kernels, cant be that much extra overhead.
thanks in advance!
More information about the lttng-dev