Hollis Blanchard wrote:
> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote:
>>
>>> Hmm, while we're on the subject, I'm not sure what the best way to
>>> automatically byteswap will be. It probably isn't worth it to
>>> convert all trace data to a standard ordering (which would add
>>> overhead to tracing), but I suppose there is no metadata in the
>>> trace log? A command line switch might be inconvenient but
>>> inevitable.
>>
>> A tricky approach is that we insert medadata to the trace file before
> reading the trace log, so that the analysis tool can look at the
> medadata to check whether we need to convert byte order?
>
> Actually, can't we lose trace records? It would be unfortunate if the
> magic metadata record was overwritten by the trace data. Perhaps a
> 1-byte "flags" variable at the beginning of each record could
> indicate the data's endianness?
>
> Another option would be to have the "kvmtrace" tool transcribe the
> data itself. I think that would be fine, since kvmtrace must run on
> the target anyways, but your kvmtrace implementation doesn't actually
> understand the format of the data.
>
> Actually... we could have kvmtrace itself insert the metadata, so
> there would be no chance of it being overwritten in the kernel
> buffers. The header could be written in tip_open_output(), and update
> fs_size accordingly.
>
Yes, let kvmtrace insert the metadata is more reasonable.
> Do you have any suggestions for the format of the metadata? I'm not
> sure how it should fit into the record format expected by
> kvmtrace_format.
I think maybe it can like this:
struct metadata {
u32 magic;
u64 extra; /* it is redundant, only use to fit into
record. */
}
kvmtrace_format can check magic to judge whethe we need to convert byte
order.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
