qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 5/6] trace: remove use of event ID enums from


From: Lluís Vilanova
Subject: Re: [Qemu-devel] [PATCH v2 5/6] trace: remove use of event ID enums from APIs
Date: Thu, 15 Sep 2016 14:20:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Daniel P Berrange writes:

> On Thu, Sep 15, 2016 at 01:26:06AM +0200, Lluís Vilanova wrote:
>> Daniel P Berrange writes:
>> 
>> > Since there will shortly be multiple event groups allowed,
>> > we can no longer use the TraceEventID and TraceEventVCPUID
>> > enums in the trace control APIs. There will in fact be
>> > multiple distinct enums, and the enum values will only be
>> > required to be unique per group.
>> 
>> This patch serves no purpose without the event group patches.
>> 
>> Also, AFAIR TraceEventVCPUID still needs to be a flat space (they're all 
>> used as
>> bitmask indexes), so keeping the enum won't lose any re-compilation benefit.
>> 
>> And without wanting to sound like a broken record, you can make the
>> "TRACE_${EVENTNAME}" IDs be global Event* variables (statically initialized 
>> in
>> "trace/generated-events.c"). That still allows using their names in the 
>> macros,
>> avoids having a (two-level) tree of events, and eliminates the need for the
>> Event::id member (and the trace_event_get_id() function).

> Regardless of whether its used in the public API, we still need to
> be able to assign a unique 32bit event ID to every event, because
> simpletrace currently needs to output that in its trace files.

> That said, i have been wondering if people are very tied to the
> current simple trace output format ?  My ideal solution would be
> for us to dynamically assign id values to trace events when QEMU
> starts up.

> If we did this, hen in the simpletrace output file, we would have
> to insert a new record type which records an (event name, ID)
> value mapping, the first time any individual event type is
> emitted.

> Thus when simpletrace.py comes to load the trace data, instead
> of using the event ID to lookup the event directly, it would use
> the event ID to get the name from the trace data, and then lookup
> the event based on name.

A self-describing simpletrace would be so much better... Instead of registering
event types the first time they're emitted, it'd be more efficient (and probably
simpler) to register them during initialization of the trace subsystem.

Probably not worth the effort, but you also have the self-describing CTF trace
format. Already has tools for reading, converting and visualizing traces.



>> [...]
>> > diff --git a/trace/simple.c b/trace/simple.c
>> > index 2f09daf..6e8013c 100644
>> > --- a/trace/simple.c
>> > +++ b/trace/simple.c
>> > @@ -18,7 +18,7 @@
>> >  #include "trace/simple.h"
>> 
>> >  /** Trace file header event ID */
>> > -#define HEADER_EVENT_ID (~(uint64_t)0) /* avoids conflicting with 
>> > TraceEventIDs */
>> > +#define HEADER_EVENT_ID (~(uint64_t)0) /* avoids conflicting with event 
>> > IDs */
>> 
>> >  /** Trace file magic number */
>> >  #define HEADER_MAGIC 0xf2b177cb0aa429b4ULL
>> > @@ -58,7 +58,7 @@ static char *trace_file_name;
>> 
>> >  /* * Trace buffer entry */
>> >  typedef struct {
>> > -    uint64_t event; /*   TraceEventID */
>> > +    uint64_t event; /*  event ID */
>> >      uint64_t timestamp_ns;
>> >      uint32_t length;   /*    in bytes */
>> >      uint32_t pid;
>> > @@ -202,7 +202,7 @@ void trace_record_write_str(TraceBufferRecord *rec, 
>> > const char *s, uint32_t slen
rec-> rec_off = write_to_buffer(rec->rec_off, (void*)s, slen);
>> >  }
>> 
>> > -int trace_record_start(TraceBufferRecord *rec, TraceEventID event, size_t 
>> > datasize)
>> > +int trace_record_start(TraceBufferRecord *rec, uint32_t event, size_t 
>> > datasize)
>> >  {
>> >      unsigned int idx, rec_off, old_idx, new_idx;
>> >      uint32_t rec_len = sizeof(TraceRecord) + datasize;
>> > diff --git a/trace/simple.h b/trace/simple.h
>> > index 1e7de45..17ce472 100644
>> > --- a/trace/simple.h
>> > +++ b/trace/simple.h
>> > @@ -33,7 +33,7 @@ typedef struct {
>> >   *
>> >   * @arglen  number of bytes required for arguments
>> >   */
>> > -int trace_record_start(TraceBufferRecord *rec, TraceEventID id, size_t 
>> > arglen);
>> > +int trace_record_start(TraceBufferRecord *rec, uint32_t id, size_t 
>> > arglen);
>> 
>> >  /**
>> >   * Append a 64-bit argument to a trace record
>> 
>> Not incorrect, but it's weird that the simple backend emits 64-bit 
>> identifiers
>> while QEMU uses 32-bit ones.

> The trace_record_start method *is* given a 32-bit id value not a 64-bit value.
> That comment you're quoting here is nothing todo with the ID values, it is
> about writing 64-bit parameter values.

Makes sense.


Cheers,
  Lluis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]