~~~
`TRACEPOINT_PROVIDER` defines the name of the provider to which the
-following tracepoint definitions will belong. It is used internally by
+following tracepoint definitions belong. It is used internally by
LTTng-UST headers and _must_ be defined. Since `TRACEPOINT_PROVIDER`
could have been defined by another header file also included by the same
C source file, the best practice is to undefine it first.
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`:
#include <lttng/tracepoint.h>
~~~
-This will also allow the application to use the `tracepoint()` macro.
+This also allows the application to use the `tracepoint()` macro.
Next is a list of `TRACEPOINT_EVENT()` macro calls which create the
-actual tracepoint definitions. We will skip this for the moment and
+actual tracepoint definitions. We skip this for the moment and
come back to how to use `TRACEPOINT_EVENT()`
[in a later section](#doc-defining-tracepoints). Just pay attention to
the first argument: it's always the name of the tracepoint provider
~~~
When `TRACEPOINT_CREATE_PROBES` is defined, the macros used in `tp.h`,
-which is included just after, will actually create the source code for
+which is included just after, actually create the source code for
LTTng-UST probes (global data structures and functions) out of your
tracepoint definitions. How exactly this is done is out of this text's scope.
`TRACEPOINT_CREATE_PROBES` is discussed further
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