From: Philippe Proulx Date: Fri, 4 Sep 2015 02:26:16 +0000 (-0400) Subject: Remove latin abbreviations X-Git-Url: http://git.liburcu.org/?a=commitdiff_plain;h=4d46e8c0be2957758addfa997ba7cece5a5aada6;p=lttng-docs.git Remove latin abbreviations Signed-off-by: Philippe Proulx --- diff --git a/contents/nuts-and-bolts/intro.md b/contents/nuts-and-bolts/intro.md index 4015633..ba77f89 100644 --- a/contents/nuts-and-bolts/intro.md +++ b/contents/nuts-and-bolts/intro.md @@ -48,7 +48,7 @@ designed to record much lower-level events that occur much more frequently than log messages, often in the thousands per second range, with very little execution overhead. Logging is more appropriate for very high-level analysis of less frequent events: user accesses, -exceptional conditions (e.g., errors, warnings), database +exceptional conditions (errors and warnings, for example), database transactions, instant messaging communications, etc. More formally, logging is one of several use cases that can be accomplished with tracing. diff --git a/contents/preface.md b/contents/preface.md index d7fea23..1fedc25 100644 --- a/contents/preface.md +++ b/contents/preface.md @@ -101,8 +101,7 @@ as linear as possible. applications and the Linux kernel, how to control tracing sessions using the `lttng` command line tool, and miscellaneous practical use cases. - 6. [Reference](#doc-reference) contains references of LTTng components, - e.g., links to online manpages and to various APIs. + 6. [Reference](#doc-reference) contains references of LTTng components. We recommend that you read the above chapters in this order, although some of them may be skipped depending on your situation. You may skip diff --git a/contents/understanding-lttng/plumbing/lttng-sessiond.md b/contents/understanding-lttng/plumbing/lttng-sessiond.md index a1bb7f2..6e298e4 100644 --- a/contents/understanding-lttng/plumbing/lttng-sessiond.md +++ b/contents/understanding-lttng/plumbing/lttng-sessiond.md @@ -44,7 +44,7 @@ Session daemons run on a per-user basis. Knowing this, multiple instances of `lttng-sessiond` may run simultaneously, each belonging to a different user and each operating independently of the others. Only `root`'s session daemon, however, may control LTTng kernel modules -(i.e. the kernel tracer). With that in mind, if a user has no root +(that is, the kernel tracer). With that in mind, if a user has no root access on the target system, he cannot trace the system's kernel, but should still be able to trace its own instrumented applications. diff --git a/contents/using-lttng/controlling-tracing/enabling-disabling-channels/intro.md b/contents/using-lttng/controlling-tracing/enabling-disabling-channels/intro.md index f966149..062c182 100644 --- a/contents/using-lttng/controlling-tracing/enabling-disabling-channels/intro.md +++ b/contents/using-lttng/controlling-tracing/enabling-disabling-channels/intro.md @@ -38,7 +38,7 @@ default parameters in the current tracing session.

Note:Because of a current limitation, all channels must be created prior to beginning tracing in a - given tracing session, i.e. before the first time you do + given tracing session, that is before the first time you do lttng start.

diff --git a/contents/using-lttng/controlling-tracing/lttng-live.md b/contents/using-lttng/controlling-tracing/lttng-live.md index dbe6930..ef6c9af 100644 --- a/contents/using-lttng/controlling-tracing/lttng-live.md +++ b/contents/using-lttng/controlling-tracing/lttng-live.md @@ -72,7 +72,7 @@ babeltrace --input-format lttng-live net://localhost Then, choose a tracing session and start viewing events as they arrive -using LTTng live, e.g.: +using LTTng live: 

 babeltrace --input-format lttng-live net://localhost/host/hostname/my-session
diff --git a/contents/using-lttng/instrumenting/advanced-techniques/32-bit-on-64-bit/building-32-bit-lttng-ust.md b/contents/using-lttng/instrumenting/advanced-techniques/32-bit-on-64-bit/building-32-bit-lttng-ust.md
index 340512c..c1317cf 100644
--- a/contents/using-lttng/instrumenting/advanced-techniques/32-bit-on-64-bit/building-32-bit-lttng-ust.md
+++ b/contents/using-lttng/instrumenting/advanced-techniques/32-bit-on-64-bit/building-32-bit-lttng-ust.md
@@ -29,7 +29,7 @@ of Userspace RCU and other dependencies.
 

 

     In this case, make sure to set LDFLAGS to all the
-    relevant 32-bit library paths, e.g.,
+    relevant 32-bit library paths, for example,
     LDFLAGS="-L/usr/lib32 -L/usr/lib/i386-linux-gnu".
 

 
@@ -37,8 +37,8 @@ of Userspace RCU and other dependencies.
 

 

     Note:You may add options to
-    ./configure if you need them, e.g., for
-    Java and SystemTap support. Look at
+    ./configure if you need them (for
+    Java and SystemTap support, for example). Look at
     ./configure --help for more information.
 

 

diff --git a/contents/using-lttng/instrumenting/c-application/building-linking/dynamic-linking.md b/contents/using-lttng/instrumenting/c-application/building-linking/dynamic-linking.md
index 468cdbf..4e02f9c 100644
--- a/contents/using-lttng/instrumenting/c-application/building-linking/dynamic-linking.md
+++ b/contents/using-lttng/instrumenting/c-application/building-linking/dynamic-linking.md
@@ -27,8 +27,8 @@ much the same as the static library method, except that:
 
 Regarding `TRACEPOINT_DEFINE` and `TRACEPOINT_PROBE_DYNAMIC_LINKAGE`,
 the recommended practice is to use a separate C source file in your
-application to define them, and then include the tracepoint provider
-header files afterwards, e.g.:
+application to define them, then include the tracepoint provider
+header files afterwards. For example:
 
 ~~~ c
 #define TRACEPOINT_DEFINE
@@ -87,8 +87,8 @@ provider shared library _before_ the application actually starts:
 

     For example, statically linking a tracepoint provider to a
     shared object which is to be dynamically loaded by an application
-    (e.g., a plugin) is not safe: the shared object, which contains the
-    tracepoint provider, could be dynamically closed
+    (a plugin, for example) is not safe: the shared object, which
+    contains the tracepoint provider, could be dynamically closed
     (dlclose()) at any time by the application.
 

 
diff --git a/contents/using-lttng/instrumenting/c-application/building-linking/static-linking.md b/contents/using-lttng/instrumenting/c-application/building-linking/static-linking.md
index 23e049a..8d80a92 100644
--- a/contents/using-lttng/instrumenting/c-application/building-linking/static-linking.md
+++ b/contents/using-lttng/instrumenting/c-application/building-linking/static-linking.md
@@ -119,7 +119,7 @@ system, replace `-ldl` with `-lc`:
 gcc -o app tp.a other.o files.o of.o your.o app.o -llttng-ust -lc
-The application can be started as usual, e.g.: +The application can be started as usual, for example: 
 ./app
diff --git a/contents/using-lttng/instrumenting/c-application/defining-tracepoints.md b/contents/using-lttng/instrumenting/c-application/defining-tracepoints.md
index bd6c076..3952994 100644
--- a/contents/using-lttng/instrumenting/c-application/defining-tracepoints.md
+++ b/contents/using-lttng/instrumenting/c-application/defining-tracepoints.md
@@ -41,8 +41,8 @@ The tracepoint name becomes the event name once events are recorded
 by the LTTng-UST tracer. It must follow the tracepoint provider name
 syntax: start with a letter and contain either letters, numbers or
 underscores. Two tracepoints under the same provider cannot have the
-same name, i.e. you cannot overload a tracepoint like you would
-overload functions and methods in C++/Java.
+same name. In other words, you cannot overload a tracepoint like you
+would overload functions and methods in C++/Java.
 
 

 
Note:The concatenation of the tracepoint
diff --git a/contents/using-lttng/instrumenting/c-application/tracef.md b/contents/using-lttng/instrumenting/c-application/tracef.md
index b4a9428..be5aad1 100644
--- a/contents/using-lttng/instrumenting/c-application/tracef.md
+++ b/contents/using-lttng/instrumenting/c-application/tracef.md
@@ -34,7 +34,8 @@ where you need to insert probes:
 #include 
 ~~~
 
-Use `tracef()` like you would use `printf()` in your source code, e.g.:
+Use `tracef()` like you would use `printf()` in your source code, for
+example:
 
 ~~~ c
     /* ... */
diff --git a/contents/using-lttng/instrumenting/c-application/tracepoint-provider.md b/contents/using-lttng/instrumenting/c-application/tracepoint-provider.md
index b12b17e..ce59741 100644
--- a/contents/using-lttng/instrumenting/c-application/tracepoint-provider.md
+++ b/contents/using-lttng/instrumenting/c-application/tracepoint-provider.md
@@ -110,7 +110,8 @@ variables).

 
 The tracepoint provider is a group of tracepoint definitions; its chosen
 name should reflect this. A hierarchy like Java packages is recommended,
-using underscores instead of dots, e.g., `org_company_project_component`.
+using underscores instead of dots, for example,
+`org_company_project_component`.
 
 Next is `TRACEPOINT_INCLUDE`:
 
@@ -178,7 +179,7 @@ tracepoint definitions. How exactly this is done is out of this text's scope.
 in [Building/linking tracepoint providers and the user application](#doc-building-tracepoint-providers-and-user-application).
 
 You could include other header files like `tp.h` here to create the probes
-of different tracepoint providers, e.g.:
+of different tracepoint providers, for example:
 
 ~~~ c
 #define TRACEPOINT_CREATE_PROBES
diff --git a/contents/using-lttng/instrumenting/instrumenting-linux-kernel/instrumenting-out-of-tree-linux-kernel.md b/contents/using-lttng/instrumenting/instrumenting-linux-kernel/instrumenting-out-of-tree-linux-kernel.md
index ce1ae11..2eecabd 100644
--- a/contents/using-lttng/instrumenting/instrumenting-linux-kernel/instrumenting-out-of-tree-linux-kernel.md
+++ b/contents/using-lttng/instrumenting/instrumenting-linux-kernel/instrumenting-out-of-tree-linux-kernel.md
@@ -26,7 +26,7 @@ build time verification:
 
 The preferred, flexible way to include your module's mainline
 tracepoint definition header is to put it in a specific directory
-relative to your module's root, e.g., `tracepoints`, and include it
+relative to your module's root (`tracepoints`, for example) and include it
 relative to your module's root directory in the LTTng custom probe's
 source:
 
diff --git a/contents/using-lttng/instrumenting/intro.md b/contents/using-lttng/instrumenting/intro.md
index b8a8198..a75227d 100644
--- a/contents/using-lttng/instrumenting/intro.md
+++ b/contents/using-lttng/instrumenting/intro.md
@@ -15,8 +15,8 @@ All the previous examples have something in common: they rely on
 skin, cardiac monitoring would be futile.
 
 LTTng, as a tracer, is no different from the real life examples above.
-If you're about to trace a software system, i.e. record its history of
-execution, you better have probes in the subject you're
+If you're about to trace a software system or, put in other words, record its
+history of execution, you better have probes in the subject you're
 tracing: the actual software. Various ways were developed to do this.
 The most straightforward one is to manually place probes, called
 _tracepoints_, in the software's source code. The Linux kernel tracing
diff --git a/contents/whats-new.md b/contents/whats-new.md
index 471d049..d5a0006 100644
--- a/contents/whats-new.md
+++ b/contents/whats-new.md
@@ -16,7 +16,7 @@ commands of the `lttng` tool.
 LTTng-modules has supported system call tracing for a long time,
 but until now, it was only possible to record either all of them,
 or none of them. LTTng 2.6 allows the user to record specific
-system call events, e.g.:
+system call events, for example:
 
 
 lttng enable-event --kernel --syscall open,fork,chdir,pipe