On 11/29/2011 06:26 PM, Stefan Hajnoczi wrote:
On Tue, Nov 29, 2011 at 12:35 PM, Markus Armbruster wrote:
Stefan Hajnoczi 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 a
On Tue, Nov 29, 2011 at 12:35 PM, Markus Armbruster wrote:
> Stefan Hajnoczi 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, the
Stefan Hajnoczi 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; /*
On Tue, Nov 29, 2011 at 11:34 AM, Stefan Hajnoczi wrote:
> On Tue, Nov 29, 2011 at 8:29 AM, Harsh Bora 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 co
On Tue, Nov 29, 2011 at 8:29 AM, Harsh Bora 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 tr
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