[lttng-docs.git] / contents / whats-new.md

---
id: whats-new
---

LTTng 2.7 ships with a generous list of new features, with essential
additions to all the project's components.

Dynamic filtering of user space tracepoints has been available for
quite some time now
(see [Enabling and disabling events](#doc-enabling-disabling-events)).
LTTng 2.7 adds filtering support to kernel events as well. For example:

<pre class="term">
lttng enable-event --kernel irq_handler_entry --filter 'irq == 28'
</pre>

LTTng 2.7 also adds wildcard support for kernel event names:

<pre class="term">
lttng enable-event --kernel 'sched_*'
</pre>

On the user space tracing side, the new [`tracelog()`](#doc-tracelog)
facility allows users to easily migrate from logging to tracing.
`tracelog()` is similar to [`tracef()`](#doc-tracef), but accepts
an additional log level parameter.

The new `--shm-path` option of `lttng create` can be used to specify the
path where the shared memory holding the ring buffers are
created. This feature is useful when used with persistent memory file
systems to extract the latest recorded trace data in the event of a
crash requiring a reboot. The new `lttng-crash` command line
utility can extract trace data from such a file (see
[Recording trace data on persistent memory file systems](#doc-persistent-memory-file-systems)).

LTTng-modules 2.7 and LTTng-UST 2.7 can rely on user plugins
to provide custom clock sources to their tracer.
LTTng-UST can also load a user plugin to retrieve the current CPU number.
This feature exists for very advanced use cases. See
the <a href="https://github.com/lttng/lttng-ust/tree/master/doc/examples/clock-override" class="ext">clock-override</a>
and <a href="https://github.com/lttng/lttng-ust/tree/master/doc/examples/getcpu-override" class="ext">getcpu-override</a>
examples for more details.

Python developers can now benefit from the new
[LTTng-UST Python agent](#doc-python-application),
a Python&nbsp;2/3-compatible package which allows standard Python logging
using the `logging` module to output log entries to an LTTng trace.

Last but not least, the new `lttng track` and `lttng untrack` commands
make [<abbr title="process ID">PID</abbr> tracking](#doc-pid-tracking)
super-fast for both the kernel and the user space domains. When one or
more PIDs are tracked, only the processes having those PIDs are allowed
to emit enabled events.

Moreover, LTTng 2.7 boasts great stability, benifiting from piles of
bug fixes and more-than-welcome internal refactorings.

To learn more about the new features of LTTng 2.7, see
<a href="" class="ext">the release announcement</a>.
Commit	Line	Data
	1	---
	2	id: whats-new
	3	---
	4
	5	LTTng 2.7 ships with a generous list of new features, with essential
	6	additions to all the project's components.
	7
	8	Dynamic filtering of user space tracepoints has been available for
	9	quite some time now
	10	(see [Enabling and disabling events](#doc-enabling-disabling-events)).
	11	LTTng 2.7 adds filtering support to kernel events as well. For example:
	12
	13	<pre class="term">
	14	lttng enable-event --kernel irq_handler_entry --filter 'irq == 28'
	15	</pre>
	16
	17	LTTng 2.7 also adds wildcard support for kernel event names:
	18
	19	<pre class="term">
	20	lttng enable-event --kernel 'sched_*'
	21	</pre>
	22
	23	On the user space tracing side, the new [`tracelog()`](#doc-tracelog)
	24	facility allows users to easily migrate from logging to tracing.
	25	`tracelog()` is similar to [`tracef()`](#doc-tracef), but accepts
	26	an additional log level parameter.
	27
	28	The new `--shm-path` option of `lttng create` can be used to specify the
	29	path where the shared memory holding the ring buffers are
	30	created. This feature is useful when used with persistent memory file
	31	systems to extract the latest recorded trace data in the event of a
	32	crash requiring a reboot. The new `lttng-crash` command line
	33	utility can extract trace data from such a file (see
	34	[Recording trace data on persistent memory file systems](#doc-persistent-memory-file-systems)).
	35
	36	LTTng-modules 2.7 and LTTng-UST 2.7 can rely on user plugins
	37	to provide custom clock sources to their tracer.
	38	LTTng-UST can also load a user plugin to retrieve the current CPU number.
	39	This feature exists for very advanced use cases. See
	40	the <a href="https://github.com/lttng/lttng-ust/tree/master/doc/examples/clock-override" class="ext">clock-override</a>
	41	and <a href="https://github.com/lttng/lttng-ust/tree/master/doc/examples/getcpu-override" class="ext">getcpu-override</a>
	42	examples for more details.
	43
	44	Python developers can now benefit from the new
	45	[LTTng-UST Python agent](#doc-python-application),
	46	a Python 2/3-compatible package which allows standard Python logging
	47	using the `logging` module to output log entries to an LTTng trace.
	48
	49	Last but not least, the new `lttng track` and `lttng untrack` commands
	50	make [<abbr title="process ID">PID</abbr> tracking](#doc-pid-tracking)
	51	super-fast for both the kernel and the user space domains. When one or
	52	more PIDs are tracked, only the processes having those PIDs are allowed
	53	to emit enabled events.
	54
	55	Moreover, LTTng 2.7 boasts great stability, benifiting from piles of
	56	bug fixes and more-than-welcome internal refactorings.
	57
	58	To learn more about the new features of LTTng 2.7, see
	59	<a href="" class="ext">the release announcement</a>.