Re: [lttng-dev] C API message iterator example for libbabeltrace2

[Simon Marchi via lttng-dev]

On 8/12/22 09:19, Maksim Khmelevskiy via lttng-dev wrote:
> Hi,
>

> there is a nice py message iterator example
>  but for C
> API only plugins are covered with examples, do you think it would make
> sense to create an example of a standalone application which simply
> uses `source.ctf.fs` as source and iterates over all messages? It
> would be nice hint for those who want to see an example of graph
> creation with all the code in one file.

Hi Maksim,

I'm not sure which example you are referring to exactly.  But in Python,
we have the high-level TraceCollectionMessageIterator object, which does
roughly:

 - Instantiate source and filter components according to the provided
   specs, including automatic source discovery
 - Instantiate a flt.utils.muxer component to merge the streams from all
   sources ports
 - Instantiate a sink component that presents the events as a Python
   iterable
 - Connect the ports of all these components
 - More things that are irrelevant here

There is no such high-level object in the C interface, so you have
to do all this by hand, it will necessarily be much more verbose.  It
would be nice to have the equivalent of TraceCollectionMessageIterator
in the C API, it is just not done yet due to lack of resources.

I did search in the documentation for an example program that uses the C
API to create and run a graph, and I haven't found one.  I agree that
adding one would be nice.  I'll look into writing one.

Regarding your use case:

> I'm interested in that example because I want to transform CTF file
> into list of C structures representing messages.

I have some questions:

 - Is the data you want to convert found in the metadata of the traces
   (description of event types) of in the payload of events?
 - Why do you want to write this in C instead of Python?  It sounds like
   it would be much faster to write in Python (with
   TraceCollectionMessageIterator), and it doesn't sound like something
   where the performance is critical (but of course I don't have the
   full context).
 - Why do you need to write an application where you create and run the
   graph yourself?  Could you instead just write your sink component
   class (which reads the messages and writes your output files),
   packaged in a plugin and use it through the babeltrace2 command-line:

 $ babeltrace2 /path/to/ctf/trace -c sink.foo.bar -p 'output="out.h"'

   ?  This way, you just have to care about writing your component
   class, which does the conversion you need.

Simon
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [RELEASE] LTTng-modules 2.12.10 and 2.13.5 (Linux kernel tracer)

[Mathieu Desnoyers via lttng-dev]

Hi,

This is a release announcement for the two currently maintained stable branches
of the LTTng kernel tracer.

* New in these releases:

Version 2.12.10 and 2.13.5 fix tracepoint instrumentation to support stable 
kernels in the
version range v5.15.58 to 5.16. They also fix incorrect stub prototypes for
CONFIG_HAVE_SYSCALL_TRACEPOINTS=n. A minor fix to tie compaction probe build to
CONFIG_COMPACTION has also been added.

Version 2.13.5 updates the tracepoint instrumentation to support Linux kernel
v5.19, and v6.0-rc1.

Feedback is welcome,

Thanks,

Mathieu

Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

[lttng-dev] [RELEASE] LTTng-ust 2.12.6 and 2.13.4 (Linux user-space tracer)

[Mathieu Desnoyers via lttng-dev]

Hi,

This is a release announcement for the currently maintained stable
branches of the LTTng-UST project. Versions 2.12.6 and 2.13.4 are
now available.

* New in these releases:

In 2.13.4, a compile-time check that disallows using types other
than integer or pointer for tracepoint array and sequence fields
has been removed in C. This is because the check relies on pointer
arithmetic, which does not support opaque pointer types, which was
therefore a regression.

In both 2.12.6 and 2.13.4, the mechanism to get the maximum cpu
number value has been changed to not rely on sysconf(3)
_SC_NPROCESSORS_CONF, but rather use /sys/devices/system/cpu/possible
on Linux. This fixes an issue observed with recent lxc, which
caused scenarios where holes in the configured CPU list causes
the returned value to be lower than the maximum cpu number + 1.

In both 2.12.6 and 2.13.4, the function lttng_ust_ctl_duplicate_ust_object_data
now returns a negative error value, fixing a segmentation fault on error
in lttng-tools.

In both 2.12.6 and 2.13.4, spurious futex wakeups are now handled
correctly. Failure to do so did not cause any user-observable issues
other than using slightly more CPU time than strictly needed, because
this spurious wakeup would only cause an additional connection attempt
to the session daemon to fail.

Feedback is welcome,

Thanks,

Mathieu

Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev