All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harsh Bora <harsh@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2
Date: Wed, 30 Nov 2011 11:37:02 +0530	[thread overview]
Message-ID: <4ED5C806.9050109@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJSP0QVvmusMJMAaptg22TfYvu+6YMSdrH+yi_L012oUieeZ4w@mail.gmail.com>

On 11/29/2011 06:26 PM, Stefan Hajnoczi wrote:
> On Tue, Nov 29, 2011 at 12:35 PM, Markus Armbruster<armbru@redhat.com>  wrote:
>> Stefan Hajnoczi<stefanha@gmail.com>  writes:
>>
>> [...]
>>> 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];
>>
>> 16 bit length?  Sure you want that?
>
> You're right, it's more future-proof to use a larger type.  Since I
> said uint32_t length in TraceRecord, uint32_t here would work well.

Makes sense to store size info only for strings as long as we rely on 
trace-events file to identify other meta-data about trace-events.

thanks,
Harsh

>
> Stefan
>

      reply	other threads:[~2011-11-30  6:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  8:29 [Qemu-devel] RFC: Design Doc for a new trace format (to support variable number/size of args per event) simpletrace-v2 Harsh Bora
2011-11-29 11:34 ` Stefan Hajnoczi
2011-11-29 11:47   ` Stefan Hajnoczi
2011-11-29 12:35     ` Markus Armbruster
2011-11-29 12:56       ` Stefan Hajnoczi
2011-11-30  6:07         ` Harsh Bora [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED5C806.9050109@linux.vnet.ibm.com \
    --to=harsh@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.