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:

> On Wed, Aug 10, 2016 at 04:33:47PM +0200, Lluís Vilanova wrote:
>> 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.

> One thing that occurred to me is that we could take a hash of the
> group name. Since we have few enough sub-dirs / groups, and a large
> enough ID space, it ought to be possible to get a hash which is
> unique. The trace tool can double check that all groups get a unique
> hash

Eliminating "@id_offset" is nice, but I would prefer to eliminate the event
hierarchy too.


>> 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).

> That means when any individual trace file is changed, we re-generate the
> world, which is exactly what this series is designed to avoid.

Nope. We re-generate /trace-events-all, but each individual file generated
afterwards (taken from the "@dir" directive) will change only if its new
contents do (the Makefile uses cmp to check if files need updating from their
corresponding timestamp file).


Cheers,
  Lluis