Re: [Qemu-devel] [PATCH 01/10] trace: [doc] Document event properties on a separate section

["Lluís Vilanova" <vilanova@ac.upc.edu>]

This series must be updated to apply on top of the patch recently accepted by
Stefan into the tracing tree [1].

[1] http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00763.html


Lluis

Lluís Vilanova writes:

> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
> ---
>  docs/tracing.txt |   22 ++++++++++++++++------
>  1 files changed, 16 insertions(+), 6 deletions(-)

> diff --git a/docs/tracing.txt b/docs/tracing.txt
> index ea29f2c..853cbf8 100644
> --- a/docs/tracing.txt
> +++ b/docs/tracing.txt
> @@ -98,12 +98,6 @@ respectively.  This ensures portability between 32- and 64-bit platforms.
>  4. Name trace events after their function.  If there are multiple trace events
>     in one function, append a unique distinguisher at the end of the name.
 
> -5. If specific trace events are going to be called a huge number of times, this
> -   might have a noticeable performance impact even when the trace events are
> -   programmatically disabled. In this case you should declare the trace event
> -   with the "disable" property, which will effectively disable it at compile
> -   time (using the "nop" backend).
> -
>  == Generic interface and monitor commands ==
 
>  You can programmatically query and control the dynamic state of trace events
> @@ -234,3 +228,19 @@ probes:
>                        --target-type system \
>                        --target-arch x86_64 \
>                        <trace-events >qemu.stp
> +
> +== Trace event properties ==
> +
> +Each event in the "trace-events" file can be prefixed with a space-separated
> +list of zero or more of the following event properties.
> +
> +=== "disable" ===
> +
> +If a specific trace event is going to be invoked a huge number of times, this
> +might have a noticeable performance impact even when the event is
> +programmatically disabled.
> +
> +In this case you should declare such event with the "disable" property. This
> +will effectively disable the event at compile time (by using the "nop" backend),
> +thus having no performance impact at all on regular builds (i.e., unless you
> +edit the "trace-events" file).



-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth