[lttng-ust.git] / doc / man / lttng-ust.3

.TH "LTTNG-UST" "3" "February 16, 2012" "" ""

.SH "NAME"
lttng-ust \(em Linux Trace Toolkit Next Generation User-Space Tracer

.SH "SYNOPSIS"

.PP
.nf
Link liblttng-ust.so with applications, following this manpage.
.fi
.SH "DESCRIPTION"

.PP
LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer, is
port of the low-overhead tracing capabilities of the LTTng kernel tracer
to user-space. The library "liblttng-ust" enables tracing of
applications and libraries.

.SH "USAGE"
.PP
The simple way to generate the lttng-ust tracepoint probes is to use the
lttng-gen-tp(1) tool. See the lttng-gen-tp(1) manpage for explanation.
.PP

.PP
Here is the way to do it manually, without the lttng-gen-tp(1) helper
script, through an example:
.PP

.SH "CREATION OF TRACEPOINT PROVIDER"

.nf

To create a tracepoint provider, within a build tree similar to
examples/easy-ust installed with lttng-ust documentation, a
sample_component_provider.h for the general layout. This manpage will
focus on the various types that can be recorded into a trace event:

TRACEPOINT_EVENT(
	/*
	 * provider name, not a variable but a string starting with a
	 * letter and containing either letters, numbers or underscores. 
	 * Needs to be the same as TRACEPOINT_PROVIDER. Needs to
	 * follow the namespacing guide-lines in lttng/tracepoint.h:
	 * 
	 * Must be included before include tracepoint provider 
	 * ex.: project_event
	 * ex.: project_component_event
	 *
	 * Optional company name goes here
	 *  ex.: com_efficios_project_component_event
	 *
	 * In this example, "sample" is the project, and "component" is the
	 * component.
	 */
	sample_component,

	/*
	 * tracepoint name, same format as sample provider. Does not
	 * need to be declared before. in this case the name is
	 * "message" 
	 */
	message,

	/*
	 * TP_ARGS macro contains the arguments passed for the tracepoint 
	 * it is in the following format
	 *	      TP_ARGS(type1, name1, type2, name2, ... type10,
				 name10)
	 * where there can be from zero to ten elements. 
	 * typeN is the datatype, such as int, struct or double **. 
	 * name is the variable name (in "int myInt" the name would be
	 * myint) 
	 *	      TP_ARGS() is valid to mean no arguments
	 *	      TP_ARGS(void) is valid too
	 */
	TP_ARGS(int, anint, int, netint, long *, values,
		 char *, text, size_t, textlen,
		 double, doublearg, float, floatarg),

	/*
	 * TP_FIELDS describes how to write the fields of the trace event. 
	 * You can put expressions in the "argument expression" area,
	 * typically using the input arguments from TP_ARGS.
	 */
	TP_FIELDS(
		/*
		 * ctf_integer: standard integer field.
		 * args: (type, field name, argument expression)
		 */
		ctf_integer(int, intfield, anint)
		ctf_integer(long, longfield, anint)

		/*
		 * ctf_integer_hex: integer field printed as hexadecimal.
		 * args: (type, field name, argument expression)
		 */
		ctf_integer_hex(int, intfield2, anint)

		/*
		 * ctf_integer_network: integer field in network byte
		 * order. (_hex: printed as hexadecimal too)
		 * args: (type, field name, argument expression)
		 */
		ctf_integer_network(int, netintfield, netint)
		ctf_integer_network_hex(int, netintfieldhex, netint)

		/*
		 * ctf_array: a statically-sized array.
		 * args: (type, field name, argument expression, value)
		 */ 
		ctf_array(long, arrfield1, values, 3)

		/*
		 * ctf_array_text: a statically-sized array, printed as
		 * a string. No need to be terminated by a null
		 * character.
		 */ 
		ctf_array_text(char, arrfield2, text, 10)

		/*
		 * ctf_sequence: a dynamically-sized array.
		 * args: (type, field name, argument expression,
		 *	type of length expression, length expression)
		 */ 
		ctf_sequence(char, seqfield1, text,
			     size_t, textlen)

		/*
		 * ctf_sequence_text: a dynamically-sized array, printed
		 * as string. No need to be null-terminated.
		 */
		ctf_sequence_text(char, seqfield2, text,
			     size_t, textlen)

		/*
		 * ctf_string: null-terminated string.
		 * args: (field name, argument expression)
		 */
		ctf_string(stringfield, text)

		/*
		 * ctf_float: floating-point number.
		 * args: (type, field name, argument expression)
		 */
		ctf_float(float, floatfield, floatarg)
		ctf_float(double, doublefield, doublearg)
	)
)

There can be an arbitrary number of tracepoint providers within an
application, but they must each have their own provider name. Duplicate
provider names are not allowed.

.fi

.SH "ASSIGNING LOGLEVEL TO EVENTS"

.nf

Optionally, a loglevel can be assigned to a TRACEPOINT_EVENT using the
following construct:

	TRACEPOINT_LOGLEVEL(< [com_company_]project[_component] >,
		< event >, < loglevel_name >)

 The first field is the provider name, the second field is the name of
the tracepoint, and the third field is the loglevel name.  A
TRACEPOINT_EVENT should be declared prior to the the TRACEPOINT_LOGLEVEL
for a given tracepoint name. The TRACEPOINT_PROVIDER must be already
declared before declaring a TRACEPOINT_LOGLEVEL.

The loglevels go from 0 to 14. Higher numbers imply the most verbosity
(higher event throughput expected.
  
Loglevels 0 through 6, and loglevel 14, match syslog(3) loglevels
semantic. Loglevels 7 through 13 offer more fine-grained selection of
debug information.
  
   TRACE_EMERG           0
   system is unusable
  
   TRACE_ALERT           1
   action must be taken immediately
  
   TRACE_CRIT            2
   critical conditions
  
   TRACE_ERR             3
   error conditions
  
   TRACE_WARNING         4
   warning conditions
  
   TRACE_NOTICE          5
   normal, but significant, condition
  
   TRACE_INFO            6
   informational message
  
   TRACE_DEBUG_SYSTEM    7
   debug information with system-level scope (set of programs)
  
   TRACE_DEBUG_PROGRAM   8
   debug information with program-level scope (set of processes)
  
   TRACE_DEBUG_PROCESS   9
   debug information with process-level scope (set of modules)
  
   TRACE_DEBUG_MODULE    10
   debug information with module (executable/library) scope (set of
   units)
  
   TRACE_DEBUG_UNIT      11
   debug information with compilation unit scope (set of functions)
  
   TRACE_DEBUG_FUNCTION  12
   debug information with function-level scope
  
   TRACE_DEBUG_LINE      13
   debug information with line-level scope (TRACEPOINT_EVENT default)
  
   TRACE_DEBUG           14
   debug-level message (trace_printf default)

See lttng(1) for information on how to use LTTng-UST loglevels.

.fi

.SH "ADDING TRACEPOINTS TO YOUR CODE"

.nf

Include the provider header in each C files you plan to instrument,
following the building/linking directives in the next section.

For instance, add within a function:

		tracepoint(ust_tests_hello, tptest, i, netint, values,
			text, strlen(text), dbl, flt);

As a call to the tracepoint. It will only be activated when requested by
lttng(1) through lttng-sessiond(8).

.fi

.SH "BUILDING/LINKING THE TRACEPOINT PROVIDER"

.nf
There are 2 ways to compile the Tracepoint Provider with the
application: either statically or dynamically. Please follow
carefully:

  1.1) Compile the Tracepoint provider with the application, either
       directly or through a static library (.a):
    - Into exactly one object of your application: define
      "TRACEPOINT_DEFINE" and include the tracepoint provider.
    - Use "\-I." for the compilation unit containing the tracepoint
      provider include (e.g. tp.c).
    - Link application with "\-ldl".
    - If building the provider directly into the application,
      link the application with "\-llttng-ust".
    - If building a static library for the provider, link the static
      library with "\-llttng-ust".
    - Include the tracepoint provider header into all C files using
      the provider.
    - Example:
        tests/hello/  hello.c tp.c ust_tests_hello.h Makefile.example

  2) Compile the Tracepoint Provider separately from the application,
     using dynamic linking:
    - Into exactly one object of your application: define
      "TRACEPOINT_DEFINE" _and_ also define
      "TRACEPOINT_PROBE_DYNAMIC_LINKAGE", then include the tracepoint
      provider header.
    - Include the tracepoint provider header into all instrumented C
      files that use the provider.
    - Compile the tracepoint provider with "\-I.".
    - Link the tracepoint provider with "\-llttng-ust".
    - Link application with "\-ldl".
    - Set a LD_PRELOAD environment to preload the tracepoint provider
      shared object before starting the application when tracing is
      needed.
    - Example:
      - tests/demo/   demo.c  tp*.c ust_tests_demo*.h demo-trace

  - Note about dlopen() usage: due to locking side-effects due to the
    way libc lazily resolves Thread-Local Storage (TLS) symbols when a
    library is dlopen'd, linking the tracepoint probe or liblttng-ust
    with dlopen() is discouraged. They should be linked with the
    application using "\-llibname" or loaded with LD_PRELOAD.
  - Enable instrumentation and control tracing with the "lttng" command
    from lttng-tools. See lttng-tools doc/quickstart.txt.
  - Note for C++ support: although an application instrumented with
    tracepoints can be compiled with g++, tracepoint probes should be
    compiled with gcc (only tested with gcc so far).

.fi

.SH "USING LTTNG UST WITH DAEMONS"

.nf
Some extra care is needed when using liblttng-ust with daemon
applications that call fork(), clone(), or BSD rfork() without a
following exec() family system call. The library "liblttng-ust-fork.so"
needs to be preloaded for the application (launch with e.g.
LD_PRELOAD=liblttng-ust-fork.so appname).

.fi

.SH "ENVIRONMENT VARIABLES"

.PP
.IP "LTTNG_UST_DEBUG"
Activate liblttng-ust debug output.
.PP
.IP "LTTNG_UST_REGISTER_TIMEOUT"
The environment variable "LTTNG_UST_REGISTER_TIMEOUT" can be used to
specify how long the applications should wait for sessiond
"registration done" command before proceeding to execute the main
program. The default is 3000ms (3 seconds). The timeout value is
specified in milliseconds. The value 0 means "don't wait". The value
\-1 means "wait forever". Setting this environment variable to 0 is
recommended for applications with time constraints on the process
startup time.
.PP

.SH "SEE ALSO"

.PP
lttng-gen-tp(1), lttng(1), babeltrace(1), lttng-sessiond(8)
.PP

.SH "COMPATIBILITY"

.PP
Older lttng-ust libraries reject more recent, and incompatible, probe
providers. Newer lttng-ust librairies accept older probe providers, even
though some newer features might not be available with those providers.
.PP

.SH "BUGS"

.PP
LTTng-UST 2.0 and 2.1 lttng-ust libraries do not check for probe
provider version compatibility. This can lead to out-of-bound accesses
when using a more recent probe provider with an older lttng-ust library.
These error only trigger when tracing is active. This issue has been
fixed in LTTng-UST 2.2.

If you encounter any issues or usability problem, please report it on
our mailing list <lttng-dev@lists.lttng.org> to help improve this
project.
.SH "CREDITS"

liblttng-ust is distributed under the GNU Lesser General Public License
version 2.1. The headers are distributed under the MIT license.
.PP
See http://lttng.org for more information on the LTTng project.
.PP
Mailing list for support and development: <lttng-dev@lists.lttng.org>.
.PP
You can find us on IRC server irc.oftc.net (OFTC) in #lttng.
.PP
.SH "THANKS"

Thanks to Ericsson for funding this work, providing real-life use-cases,
and testing.

Special thanks to Michel Dagenais and the DORSAL laboratory at
Polytechnique de Montreal for the LTTng journey.
.PP
.SH "AUTHORS"

.PP
liblttng-ust was originally written by Mathieu Desnoyers, with additional
contributions from various other people. It is currently maintained by
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>.
.PP
Commit	Line	Data
eba411c6 MD	1	.TH "LTTNG-UST" "3" "February 16, 2012" "" ""
	2
	3	.SH "NAME"
	4	lttng-ust \(em Linux Trace Toolkit Next Generation User-Space Tracer
	5
	6	.SH "SYNOPSIS"
	7
	8	.PP
	9	.nf
	10	Link liblttng-ust.so with applications, following this manpage.
	11	.fi
	12	.SH "DESCRIPTION"
	13
	14	.PP
	15	LTTng-UST, the Linux Trace Toolkit Next Generation Userspace Tracer, is
	16	port of the low-overhead tracing capabilities of the LTTng kernel tracer
	17	to user-space. The library "liblttng-ust" enables tracing of
	18	applications and libraries.
	19
	20	.SH "USAGE"
	21	.PP
	22	The simple way to generate the lttng-ust tracepoint probes is to use the
	23	lttng-gen-tp(1) tool. See the lttng-gen-tp(1) manpage for explanation.
	24	.PP
	25
	26	.PP
	27	Here is the way to do it manually, without the lttng-gen-tp(1) helper
	28	script, through an example:
	29	.PP
	30
	31	.SH "CREATION OF TRACEPOINT PROVIDER"
	32
	33	.nf
	34
	35	To create a tracepoint provider, within a build tree similar to
	36	examples/easy-ust installed with lttng-ust documentation, a
	37	sample_component_provider.h for the general layout. This manpage will
	38	focus on the various types that can be recorded into a trace event:
	39
	40	TRACEPOINT_EVENT(
	41	/*
	42	* provider name, not a variable but a string starting with a
	43	* letter and containing either letters, numbers or underscores.
	44	* Needs to be the same as TRACEPOINT_PROVIDER. Needs to
	45	* follow the namespacing guide-lines in lttng/tracepoint.h:
	46	*
	47	* Must be included before include tracepoint provider
	48	* ex.: project_event
	49	* ex.: project_component_event
	50	*
	51	* Optional company name goes here
	52	* ex.: com_efficios_project_component_event
	53	*
	54	* In this example, "sample" is the project, and "component" is the
	55	* component.
	56	*/
	57	sample_component,
	58
	59	/*
	60	* tracepoint name, same format as sample provider. Does not
	61	* need to be declared before. in this case the name is
	62	* "message"
	63	*/
	64	message,
65
66	/*
67	* TP_ARGS macro contains the arguments passed for the tracepoint
68	* it is in the following format
69	* TP_ARGS(type1, name1, type2, name2, ... type10,
70	name10)
71	* where there can be from zero to ten elements.
72	* typeN is the datatype, such as int, struct or double **.
73	* name is the variable name (in "int myInt" the name would be
74	* myint)
75	* TP_ARGS() is valid to mean no arguments
76	* TP_ARGS(void) is valid too
77	*/
78	TP_ARGS(int, anint, int, netint, long *, values,
79	char *, text, size_t, textlen,
80	double, doublearg, float, floatarg),
81
82	/*
83	* TP_FIELDS describes how to write the fields of the trace event.
84	* You can put expressions in the "argument expression" area,
85	* typically using the input arguments from TP_ARGS.
86	*/
87	TP_FIELDS(
88	/*
89	* ctf_integer: standard integer field.
90	* args: (type, field name, argument expression)
91	*/
92	ctf_integer(int, intfield, anint)
93	ctf_integer(long, longfield, anint)
94
95	/*
96	* ctf_integer_hex: integer field printed as hexadecimal.
97	* args: (type, field name, argument expression)
98	*/
99	ctf_integer_hex(int, intfield2, anint)
100
101	/*
102	* ctf_integer_network: integer field in network byte
103	* order. (_hex: printed as hexadecimal too)
104	* args: (type, field name, argument expression)
105	*/
106	ctf_integer_network(int, netintfield, netint)
107	ctf_integer_network_hex(int, netintfieldhex, netint)
108
109	/*
110	* ctf_array: a statically-sized array.
111	* args: (type, field name, argument expression, value)
112	*/
113	ctf_array(long, arrfield1, values, 3)
114
115	/*
116	* ctf_array_text: a statically-sized array, printed as
117	* a string. No need to be terminated by a null
118	* character.
119	*/
120	ctf_array_text(char, arrfield2, text, 10)
121
122	/*
123	* ctf_sequence: a dynamically-sized array.
124	* args: (type, field name, argument expression,
125	* type of length expression, length expression)
126	*/
127	ctf_sequence(char, seqfield1, text,
128	size_t, textlen)
129
130	/*
131	* ctf_sequence_text: a dynamically-sized array, printed
132	* as string. No need to be null-terminated.
133	*/
134	ctf_sequence_text(char, seqfield2, text,
135	size_t, textlen)
136
137	/*
138	* ctf_string: null-terminated string.
139	* args: (field name, argument expression)
140	*/
141	ctf_string(stringfield, text)
142
143	/*
144	* ctf_float: floating-point number.
145	* args: (type, field name, argument expression)
146	*/
147	ctf_float(float, floatfield, floatarg)
148	ctf_float(double, doublefield, doublearg)
149	)
150	)
62708e69 MD	151
	152	There can be an arbitrary number of tracepoint providers within an
	153	application, but they must each have their own provider name. Duplicate
	154	provider names are not allowed.
	155
eba411c6 MD	156	.fi
eba411c6 MD	157
5883c06f MD	158	.SH "ASSIGNING LOGLEVEL TO EVENTS"
	159
	160	.nf
	161
	162	Optionally, a loglevel can be assigned to a TRACEPOINT_EVENT using the
	163	following construct:
	164
	165	TRACEPOINT_LOGLEVEL(< [com_company_]project[_component] >,
	166	< event >, < loglevel_name >)
	167
	168	The first field is the provider name, the second field is the name of
	169	the tracepoint, and the third field is the loglevel name. A
	170	TRACEPOINT_EVENT should be declared prior to the the TRACEPOINT_LOGLEVEL
	171	for a given tracepoint name. The TRACEPOINT_PROVIDER must be already
	172	declared before declaring a TRACEPOINT_LOGLEVEL.
	173
	174	The loglevels go from 0 to 14. Higher numbers imply the most verbosity
	175	(higher event throughput expected.
	176
	177	Loglevels 0 through 6, and loglevel 14, match syslog(3) loglevels
	178	semantic. Loglevels 7 through 13 offer more fine-grained selection of
	179	debug information.
	180
	181	TRACE_EMERG 0
	182	system is unusable
	183
	184	TRACE_ALERT 1
	185	action must be taken immediately
	186
	187	TRACE_CRIT 2
	188	critical conditions
	189
	190	TRACE_ERR 3
	191	error conditions
	192
	193	TRACE_WARNING 4
	194	warning conditions
	195
	196	TRACE_NOTICE 5
	197	normal, but significant, condition
	198
	199	TRACE_INFO 6
	200	informational message
	201
	202	TRACE_DEBUG_SYSTEM 7
	203	debug information with system-level scope (set of programs)
	204
	205	TRACE_DEBUG_PROGRAM 8
	206	debug information with program-level scope (set of processes)
	207
	208	TRACE_DEBUG_PROCESS 9
	209	debug information with process-level scope (set of modules)
	210
	211	TRACE_DEBUG_MODULE 10
	212	debug information with module (executable/library) scope (set of
	213	units)
	214
	215	TRACE_DEBUG_UNIT 11
	216	debug information with compilation unit scope (set of functions)
	217
	218	TRACE_DEBUG_FUNCTION 12
	219	debug information with function-level scope
	220
	221	TRACE_DEBUG_LINE 13
222	debug information with line-level scope (TRACEPOINT_EVENT default)
223
224	TRACE_DEBUG 14
225	debug-level message (trace_printf default)
226
227	See lttng(1) for information on how to use LTTng-UST loglevels.
228
229	.fi
230
eba411c6 MD	231	.SH "ADDING TRACEPOINTS TO YOUR CODE"
	232
	233	.nf
	234
	235	Include the provider header in each C files you plan to instrument,
	236	following the building/linking directives in the next section.
	237
	238	For instance, add within a function:
	239
	240	tracepoint(ust_tests_hello, tptest, i, netint, values,
	241	text, strlen(text), dbl, flt);
	242
	243	As a call to the tracepoint. It will only be activated when requested by
	244	lttng(1) through lttng-sessiond(8).
	245
	246	.fi
	247
	248	.SH "BUILDING/LINKING THE TRACEPOINT PROVIDER"
	249
	250	.nf
	251	There are 2 ways to compile the Tracepoint Provider with the
	252	application: either statically or dynamically. Please follow
	253	carefully:
	254
	255	1.1) Compile the Tracepoint provider with the application, either
	256	directly or through a static library (.a):
	257	- Into exactly one object of your application: define
	258	"TRACEPOINT_DEFINE" and include the tracepoint provider.
9b6435af	259	- Use "\-I." for the compilation unit containing the tracepoint
eba411c6	260	provider include (e.g. tp.c).
9b6435af	261	- Link application with "\-ldl".
eba411c6	262	- If building the provider directly into the application,
9b6435af	263	link the application with "\-llttng-ust".
eba411c6	264	- If building a static library for the provider, link the static
881de2e9	265	library with "\-llttng-ust".
eba411c6 MD	266	- Include the tracepoint provider header into all C files using
	267	the provider.
	268	- Example:
	269	tests/hello/ hello.c tp.c ust_tests_hello.h Makefile.example
	270
	271	2) Compile the Tracepoint Provider separately from the application,
	272	using dynamic linking:
	273	- Into exactly one object of your application: define
	274	"TRACEPOINT_DEFINE" _and_ also define
	275	"TRACEPOINT_PROBE_DYNAMIC_LINKAGE", then include the tracepoint
	276	provider header.
	277	- Include the tracepoint provider header into all instrumented C
	278	files that use the provider.
9b6435af AM	279	- Compile the tracepoint provider with "\-I.".
	280	- Link the tracepoint provider with "\-llttng-ust".
	281	- Link application with "\-ldl".
eba411c6 MD	282	- Set a LD_PRELOAD environment to preload the tracepoint provider
	283	shared object before starting the application when tracing is
	284	needed.
	285	- Example:
	286	- tests/demo/ demo.c tp.c ust_tests_demo.h demo-trace
	287
	288	- Note about dlopen() usage: due to locking side-effects due to the
	289	way libc lazily resolves Thread-Local Storage (TLS) symbols when a
	290	library is dlopen'd, linking the tracepoint probe or liblttng-ust
	291	with dlopen() is discouraged. They should be linked with the
9b6435af	292	application using "\-llibname" or loaded with LD_PRELOAD.
eba411c6 MD	293	- Enable instrumentation and control tracing with the "lttng" command
eba411c6 MD	294	from lttng-tools. See lttng-tools doc/quickstart.txt.
bf62473e MD	295	- Note for C++ support: although an application instrumented with
	296	tracepoints can be compiled with g++, tracepoint probes should be
	297	compiled with gcc (only tested with gcc so far).
eba411c6 MD	298
	299	.fi
	300
a9deca90 MD	301	.SH "USING LTTNG UST WITH DAEMONS"
	302
	303	.nf
	304	Some extra care is needed when using liblttng-ust with daemon
	305	applications that call fork(), clone(), or BSD rfork() without a
	306	following exec() family system call. The library "liblttng-ust-fork.so"
	307	needs to be preloaded for the application (launch with e.g.
	308	LD_PRELOAD=liblttng-ust-fork.so appname).
	309
	310	.fi
	311
eba411c6 MD	312	.SH "ENVIRONMENT VARIABLES"
	313
	314	.PP
	315	.IP "LTTNG_UST_DEBUG"
	316	Activate liblttng-ust debug output.
	317	.PP
	318	.IP "LTTNG_UST_REGISTER_TIMEOUT"
	319	The environment variable "LTTNG_UST_REGISTER_TIMEOUT" can be used to
	320	specify how long the applications should wait for sessiond
	321	"registration done" command before proceeding to execute the main
	322	program. The default is 3000ms (3 seconds). The timeout value is
	323	specified in milliseconds. The value 0 means "don't wait". The value
9b6435af	324	\-1 means "wait forever". Setting this environment variable to 0 is
eba411c6 MD	325	recommended for applications with time constraints on the process
	326	startup time.
	327	.PP
	328
	329	.SH "SEE ALSO"
	330
	331	.PP
	332	lttng-gen-tp(1), lttng(1), babeltrace(1), lttng-sessiond(8)
	333	.PP
1b8747b1 MD	334
	335	.SH "COMPATIBILITY"
	336
	337	.PP
	338	Older lttng-ust libraries reject more recent, and incompatible, probe
	339	providers. Newer lttng-ust librairies accept older probe providers, even
	340	though some newer features might not be available with those providers.
	341	.PP
	342
eba411c6 MD	343	.SH "BUGS"
	344
	345	.PP
1b8747b1 MD	346	LTTng-UST 2.0 and 2.1 lttng-ust libraries do not check for probe
	347	provider version compatibility. This can lead to out-of-bound accesses
	348	when using a more recent probe provider with an older lttng-ust library.
	349	These error only trigger when tracing is active. This issue has been
	350	fixed in LTTng-UST 2.2.
eba411c6 MD	351
	352	If you encounter any issues or usability problem, please report it on
	353	our mailing list <lttng-dev@lists.lttng.org> to help improve this
	354	project.
	355	.SH "CREDITS"
	356
	357	liblttng-ust is distributed under the GNU Lesser General Public License
	358	version 2.1. The headers are distributed under the MIT license.
	359	.PP
	360	See http://lttng.org for more information on the LTTng project.
	361	.PP
	362	Mailing list for support and development: <lttng-dev@lists.lttng.org>.
	363	.PP
	364	You can find us on IRC server irc.oftc.net (OFTC) in #lttng.
	365	.PP
	366	.SH "THANKS"
	367
	368	Thanks to Ericsson for funding this work, providing real-life use-cases,
	369	and testing.
	370
	371	Special thanks to Michel Dagenais and the DORSAL laboratory at
	372	Polytechnique de Montreal for the LTTng journey.
	373	.PP
	374	.SH "AUTHORS"
	375
	376	.PP
	377	liblttng-ust was originally written by Mathieu Desnoyers, with additional
	378	contributions from various other people. It is currently maintained by
	379	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>.
	380	.PP