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.

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.

-- 
Hollis Blanchard
IBM Linux Technology Center

-------------------------------------------------------------------------
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

Reply via email to