"line" -> "lines" when more than one line

[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 c3519fe6b19276f75d521f9b5447e7f6660b77c0..67b34a156c2d0d83942e2fd13ca186c5b84d5175 100644 (file)
--- a/2.7/lttng-docs-2.7.txt
+++ b/2.7/lttng-docs-2.7.txt
@@ -327,8 +327,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 +350,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_
@@ -371,20 +377,19 @@ and Buildroot{nbsp}2016.08">>
 other Buildroot releases.
 
 |OpenEmbedded and Yocto
-|<<oe-yocto,`openembedded-core` layer from 1{nbsp}December 2016 until
-3{nbsp}September 2016>>
-|LTTng{nbsp}2.8 for OpenEmbedded since 3{nbsp}September 2016.
+|<<oe-yocto,Yocto Project{nbsp}2.1 _Krogoth_>> (`openembedded-core` layer)
+|LTTng{nbsp}2.8 for Yocto Project{nbsp}2.2 _Morty_.
 
 <<building-from-source,Build LTTng{nbsp}{revision} from source>> for
-other OpenEmbedded releases.
+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_:
@@ -412,7 +417,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:
 +
 --
@@ -471,7 +476,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:
 +
 --
@@ -543,8 +548,7 @@ make menuconfig
 
 LTTng{nbsp}{revision} recipes are available in the
 http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/[`openembedded-core`]
-layer of OpenEmbedded since 1{nbsp}December 2016 until
-3{nbsp}September 2016 under the following names:
+layer for Yocto Project{nbsp}2.1 _Krogoth_ under the following names:
 
 * `lttng-tools`
 * `lttng-modules`
@@ -2545,7 +2549,7 @@ holding more than one tracepoint providers.
 Once you <<tpp-header,create a tracepoint provider header file>>, you
 can use the `tracepoint()` macro in your application's
 source code to insert the tracepoints that this header
-<<defining-tracepoints,defined>> defines.
+<<defining-tracepoints,defines>>.
 
 The `tracepoint()` macro takes at least two parameters: the tracepoint
 provider name and the tracepoint name. The corresponding tracepoint
@@ -2754,10 +2758,11 @@ In the following diagrams, we use the following file names:
 `libemon.so`::
   User library shared object file.
 
-The red star indicates that this object file is instrumented
-(contains code which uses the `tracepoint()` macro). The spring
-symbol between the application and a library means the application is
-linked with the library at build time.
+We use the following symbols in the diagrams of table below:
+
+[role="img-100"]
+.Symbols used in the build scenario diagrams.
+image::ust-sit-symbols.png[]
 
 We assume that path:{.} is part of the env:LD_LIBRARY_PATH environment
 variable in the following instructions.
@@ -3206,7 +3211,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]
@@ -3293,7 +3298,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]
@@ -3442,7 +3447,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]
@@ -3515,7 +3520,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]
@@ -4240,10 +4245,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