On Tue, Nov 29, 2011 at 11:34 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> On Tue, Nov 29, 2011 at 8:29 AM, Harsh Bora <ha...@linux.vnet.ibm.com> wrote:
>> Currently, Qemu provides an in-built "simple" trace backend which is simple
>> and easy to use (no additional/external dependencies) and allows developers
>> to trace events in Qemu code, however, it suffers from limitations like
>> unability to trace more than 6 elements per trace event, lack of string
>> support, etc. There are various places in Qemu code, where one would want to
>> trace events having multiple arguments including strings. This results into
>> motivation for defining an advanced, yet simple trace format which will
>> address these limitations. For the sake of convinence, let us call this new
>> trace format as simpletrace v2 (any other better name?).
>>
>> HLD for Simpletrace v2:
>> ======================
>>
>> This new trace format defines 3 types of structures for trace data
>> organization:
>>
>> 1) Trace Log Header (per log file, provides meta-data about the entire trace
>> log, like trace format version, endianness, etc.)
>> 2) Trace Event Header (per trace event, provides meta-data per trace event)
>> 3) Trace Data (per argument/data in a trace event, provides size of data
>> followed by data itself)
>>
>>
>> The Trace Log header can be defined like this:
>>
>> typedef struct {
>> uint64_t endian_magic; /* =0xAA0011FF, a magic number helps
>> identifying validity and endian-ness of trace log to its readers */
>> uint64_t pid; /* pid of qemu process can be traced here */
>> uint64_t version; /* Keeping version info as 3rd 64-bit element
>> as expected by current simpletrace format */
>> unit64_t timestamp; /* timestamp info */
>> } TraceLogHeader;
>>
>> Suggestions are invited to make this header more informative as required.
>>
>> Further, this TraceLogHeader will be followed by 0 or more Trace Event
>> Headers (further followed by trace data) as defined below:
>>
>> typedef struct {
>> uint64_t magic; /* =0xA1B2C3D4, ensures a valid trace record,
>> otherwise corrupted */
>> unit64_t id; /* unique identifer per trace event */
>> uint64_t timestamp; /* timestamp info */
>> uint64_t num_args; /* number of arguments (followed by this
>> TraceEventHeader) traced in this trace event */
>
> What exactly is num_args?
>
>> } TraceEventHeader;
>>
>> Trace Data is expected to be stored in following format followed by
>> TraceEventHeader:
>>
>> typedef struct {
>> uint64_t size; /* size of data in bytes to be read following this
>> header */
>> uint8_t data[0] /* variable sized data */
>> } TraceData;
>
> This format does not support variable-length strings in a
> self-describing way.
I used the word "self-describing". To be clear I think we should not
put any trace event metadata into the trace file. Instead we continue
to rely on having the trace-events file together with the trace file.
This keeps the trace format simple. If we do want a self-describing
trace format then I think we should use the Common Trace Format that
LTTng is working on instead of rolling our own.
So forget I said "self-describing" :). I think the only changes from
the v1 format we need are:
1. New magic number to mark v2 format.
2. Trace records are no longer fixed-length, they include a size field:
typedef struct {
uint32_t length; /* in bytes */
uint32_t reserved; /* unused */
uint64_t event;
uint64_t timestamp_ns;
uint8_t arguments[];
} TraceRecord;
3. Strings are serialized like this:
uint16_t length;
char chars[length];
These changes enable:
1. Variable number of trace event arguments.
2. Variable-length strings.
Stefan
