commit 770e047c83a1146d228a568dd3a673473ccd8d81 Author: David Goulet dgoulet@torproject.org Date: Tue Jul 14 10:09:01 2020 -0400
doc: Fix aesthetic issues in HACKING/Tracing.md
Remove all the escape character "" which is not needed for Markdown files. This also fixes the tracing event include to the correct path.
Signed-off-by: David Goulet dgoulet@torproject.org --- doc/HACKING/Tracing.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/HACKING/Tracing.md b/doc/HACKING/Tracing.md index 0f2196c3f8..d9fb2e5341 100644 --- a/doc/HACKING/Tracing.md +++ b/doc/HACKING/Tracing.md @@ -44,7 +44,7 @@ subsystem and an event name. A trace event in tor has the following standard format:
```c -tor_trace(subsystem, event_name, args...); +tor_trace(subsystem, event_name, args...); ```
The `subsystem` parameter is the name of the subsytem the trace event is in. @@ -52,7 +52,7 @@ For example that could be "scheduler" or "vote" or "hs". The idea is to add some context to the event so when we collect them we know where it's coming from.
-The `event_name` is the name of the event which adds better semantic to the +The `event_name` is the name of the event which adds better semantic to the event.
The `args` can be any number of arguments we want to collect. @@ -63,7 +63,7 @@ Here is an example of a possible tracepoint in main(): tor_trace(main, init_phase, argc); ```
-The above is a tracepoint in the `main` subsystem with `init_phase` as the +The above is a tracepoint in the `main` subsystem with `init_phase` as the event name and the `int argc` is passed to the event as one argument.
How `argc` is collected or used has nothing to do with the instrumentation @@ -73,14 +73,14 @@ have trace events without a tracer.
### Instrumentation ###
-In `src/lib/trace/events.h`, we map the high level `tor_trace()` macro to one +In `src/lib/trace/events.h`, we map the high level `tor_trace()` macro to one or many enabled instrumentation.
Currently, we have 3 types of possible instrumentation:
1. Debug
- This will map every tracepoint to `log_debug()`. However, none of the + This will map every tracepoint to `log_debug()`. However, none of the arguments will be passed on because we don't know their type nor the string format of the debug log. The output is standardized like this:
@@ -96,7 +96,7 @@ Currently, we have 3 types of possible instrumentation:
For each tracer, one will need to define the ABI in order for the tracer to be able to extract the data from the tracepoint objects. For instance, the - tracer needs to know how to print the circuit state of a `circuit_t` + tracer needs to know how to print the circuit state of a `circuit_t` object.
3. LTTng-UST @@ -111,7 +111,7 @@ Currently, we have 3 types of possible instrumentation: This section describes how the instrumentation is integrated into the build system of tor.
-By default, every tracing events are disabled in tor that is `tor_trace()` is +By default, every tracing events are disabled in tor that is `tor_trace()` is a NOP thus has no execution cost time.
To enable a specific instrumentation, there are configure options: @@ -123,8 +123,8 @@ To enable a specific instrumentation, there are configure options: 3. LTTng: `--enable-tracing-instrumentation-lttng`
They can all be used together or independently. If one of them is set, -`HAVE_TRACING` define is set. And for each instrumentation, a -`USE_TRACING_INSTRUMENTATION_<type>` is set. +`HAVE_TRACING` define is set. And for each instrumentation, a +`USE_TRACING_INSTRUMENTATION_<type>` is set.
## Adding a Tracepoint ##
@@ -132,10 +132,10 @@ This is pretty easy. Let's say you want to add a trace event in `src/feature/rend/rendcache.c`, you first need to include this file:
```c -#include "trace/events.h" +#include "lib/trace/events.h" ```
-Then, the `tor_trace()` macro can be used with the specific format detailled +Then, the `tor_trace()` macro can be used with the specific format detailled before in a previous section. As an example:
```c