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