Re: [Qemu-devel] [PATCH for-2.8 v1 60/60] trace: update docs to reflect new code generation approach

[Lluís Vilanova]

Daniel P Berrange writes:

> Describe use of per-subdir trace events files and how it impacts
> code generation.

> Signed-off-by: Daniel P. Berrange <address@hidden>
> ---
>  docs/tracing.txt | 61 
> +++++++++++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 52 insertions(+), 9 deletions(-)

> diff --git a/docs/tracing.txt b/docs/tracing.txt
> index 29f2f9a..b7ba179 100644
> --- a/docs/tracing.txt
> +++ b/docs/tracing.txt
> @@ -27,18 +27,51 @@ for debugging, profiling, and observing execution.
 
>  == Trace events ==
 
> +=== Sub-directory setup ===
> +
>  Each directory in the source tree can declare a set of static trace events
> -in a "trace-events" file. Each trace event declaration names the event, its
> -arguments, and the format string which can be used for pretty-printing:
> +in a "trace-events" file. The first (non-comment) statement in the file
> +must be "@id_offset(NN)" where NN is an integer that is unique among all
> +"trace-events" files in the QEMU source tree. The IDs can be arbitrarily
> +chosen, but extra fun the current "trace-events" files use values from the
> +"powerful number" integer sequence :-)

Can we get rid of the "@id_offset(NN)"? If we're generating a trace-events-all
all the same, we can use that to generate all the per-directory file *and* still
keep the simpler flat event ids.

For example, first we concatenate /trace-events, /io/trace-events and
/hw/usb/trace-events into /trace-events-all to produce:

   @group core
   @dir /
   # contents of /trace-events
   @group io
   @dir /io
   # contents of /io/trace-events
   @group hw_usb
   @dir /hw/usb
   # contents of /hw/usb/trace-events

Then we can use /trace-events-all to generate all the per-directory trace.h
files while ensuring a perfectly flat event identifier space (a single
generated-events.c is used).

This should minimize changes to tracing code and avoid further restrictions
(like the "top-level vcpu" one).


Cheers,
  Lluis