2.7, 2.8, 2.9: occurance -> occurrence

[lttng-docs.git] / 2.7 / lttng-docs-2.7.txt

diff --git a/2.7/lttng-docs-2.7.txt b/2.7/lttng-docs-2.7.txt
index e3cdd170408aecef7d9fb8ce69349c7685d3eb48..2708e4901cd50715c3767d0fbccab5a1cc62ebec 100644 (file)
--- a/2.7/lttng-docs-2.7.txt
+++ b/2.7/lttng-docs-2.7.txt
@@ -1,12 +1,15 @@
 The LTTng Documentation
 =======================
 Philippe Proulx <pproulx@efficios.com>
-v2.7, 25 October 2016
+v2.7, 24 July 2017
 
 
 include::../common/copyright.txt[]
 
 
+include::../common/warning-not-maintained.txt[]
+
+
 include::../common/welcome.txt[]
 
 
@@ -286,6 +289,8 @@ becomes inactive or in real-time.
 [[installing-lttng]]
 == Installation
 
+include::../common/warning-installation-outdated.txt[]
+
 **LTTng** is a set of software <<plumbing,components>> which interact to
 <<instrumenting,instrument>> the Linux kernel and user applications, and
 to <<controlling-tracing,control tracing>> (start and stop
@@ -327,8 +332,11 @@ other Ubuntu releases.
 
 |Fedora
 |_Not available_
-|LTTng{nbsp}{revision} for Fedora{nbsp}25 and Fedora{nbsp}26 (not
-released yet).
+|LTTng-tools{nbsp}{revision} and LTTng-UST{nbsp}{revision} for
+Fedora{nbsp}25 and Fedora{nbsp}26 (both are not released yet).
+
+<<building-from-source,Build LTTng-modules{nbsp}{revision} from
+source>>.
 
 <<building-from-source,Build LTTng{nbsp}{revision} from source>> for
 other Fedora releases.
@@ -347,7 +355,10 @@ other openSUSE releases.
 
 |Arch Linux
 |_Not available_
-|<<building-from-source,Build LTTng{nbsp}{revision} from source>>.
+|
+LTTng{nbsp}2.8 on the AUR.
+
+<<building-from-source,Build LTTng{nbsp}{revision} from source>>.
 
 |Alpine Linux
 |_Not available_
@@ -382,8 +393,8 @@ other Yocto releases.
 [[ubuntu]]
 === [[ubuntu-official-repositories]]Ubuntu
 
-LTTng{nbsp}{revision} is available on Ubuntu 16.04 _Xenial Xerus_. For
-previous releases of Ubuntu, <<ubuntu-ppa,use the LTTng
+LTTng{nbsp}{revision} is available on Ubuntu{nbsp}16.04 _Xenial Xerus_.
+For previous releases of Ubuntu, <<ubuntu-ppa,use the LTTng
 Stable{nbsp}{revision} PPA>>.
 
 To install LTTng{nbsp}{revision} on Ubuntu{nbsp}16.04 _Xenial Xerus_:
@@ -411,7 +422,7 @@ sudo apt-get install liblttng-ust-agent-java
 --
 
 . **If you need to instrument and trace
-  <<python-application,Python applications>>**, install the
+  <<python-application,Python{nbsp}3 applications>>**, install the
   LTTng-UST Python agent:
 +
 --
@@ -470,7 +481,7 @@ sudo apt-get install liblttng-ust-agent-java
 --
 
 . **If you need to instrument and trace
-  <<python-application,Python applications>>**, install the
+  <<python-application,Python{nbsp}3 applications>>**, install the
   LTTng-UST Python agent:
 +
 --
@@ -1617,7 +1628,7 @@ With so many similar terms, it's easy to get confused.
 An **event** is the consequence of the execution of an _instrumentation
 point_, like a tracepoint that you manually place in some source code,
 or a Linux kernel KProbe. An event is said to _occur_ at a specific
-time. Different actions can be taken upon the occurance of an event,
+time. Different actions can be taken upon the occurrence of an event,
 like record the event's payload to a buffer.
 
 An **event record** is the representation of an event in a sub-buffer. A
@@ -3205,7 +3216,7 @@ include::../common/ust-sit-step-tp-so.txt[]
 To build the instrumented user library:
 
 . In path:{emon.c}, before including path:{tpp.h}, add the
-  following line:
+  following lines:
 +
 --
 [source,c]
@@ -3292,7 +3303,7 @@ include::../common/ust-sit-step-tp-so.txt[]
 To build the instrumented user library:
 
 . In path:{emon.c}, before including path:{tpp.h}, add the
-  following line:
+  following lines:
 +
 --
 [source,c]
@@ -3441,7 +3452,7 @@ include::../common/ust-sit-step-tp-so.txt[]
 To build the instrumented user library:
 
 . In path:{emon.c}, before including path:{tpp.h}, add the
-  following line:
+  following lines:
 +
 --
 [source,c]
@@ -3514,7 +3525,7 @@ include::../common/ust-sit-step-tp-so.txt[]
 To build the instrumented user library:
 
 . In path:{emon.c}, before including path:{tpp.h}, add the
-  following line:
+  following lines:
 +
 --
 [source,c]
@@ -4239,10 +4250,8 @@ Assuming no event record is lost, having only the function addresses on
 entry is enough to create a call graph, since an event record always
 contains the ID of the CPU that generated it.
 +
-You can use a tool like
-https://sourceware.org/binutils/docs/binutils/addr2line.html[cmd:addr2line]
-to convert function addresses back to source file names and
-line numbers.
+You can use a tool like man:addr2line(1) to convert function addresses
+back to source file names and line numbers.
 
 * **path:{liblttng-ust-cyg-profile.so}** is a more robust variant
 which also works in use cases where event records might get discarded or
@@ -4826,12 +4835,12 @@ MODULE_VERSION(__stringify(LTTNG_MODULES_MAJOR_VERSION) "."
 ----
 --
 
-. Edit path:{probes/Makefile} and add your new kernel module object
+. Edit path:{probes/KBuild} and add your new kernel module object
   next to the existing ones:
 +
 --
 [source,make]
-.path:{probes/Makefile}
+.path:{probes/KBuild}
 ----
 # ...
 
@@ -5141,7 +5150,7 @@ To output LTTng traces to a non-default location:
 --
 [role="term"]
 ----
-lttng create --output=/tmp/some-directory my-session
+lttng create my-session --output=/tmp/some-directory
 ----
 --
 
@@ -6033,7 +6042,7 @@ To use LTTng live:
 --
 [role="term"]
 ----
-lttng create --live my-session
+lttng create my-session --live
 ----
 --
 +
@@ -6099,7 +6108,7 @@ To take a snapshot:
 --
 [role="term"]
 ----
-lttng create --snapshot my-session
+lttng create my-session --snapshot
 ----
 --
 +
@@ -6199,7 +6208,7 @@ trace data after a system crash:
 --
 [role="term"]
 ----
-lttng create --shm-path=/path/to/shm
+lttng create my-session -shm-path=/path/to/shm
 ----
 --
 
@@ -6846,7 +6855,7 @@ event::
   or a Linux kernel KProbe.
 +
 An event is said to _occur_ at a specific time. Different actions can
-be taken upon the occurance of an event, like record the event's payload
+be taken upon the occurrence of an event, like record the event's payload
 to a sub-buffer.
 
 <<channel-overwrite-mode-vs-discard-mode,event loss mode>>::