Liu, Eric E wrote:
> Hollis Blanchard wrote:
>> On Wednesday 16 April 2008 01:45:34 Liu, Eric E wrote:
[...]
>> 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.
>
I wanted to note that the kvmtrace tool should, but not need to know everything
about the data format.
I think of e.g. changing kernel implementations that change endianess or even
flags we don't yet know, but we might need in the future.
What about adding another debugfs entry the kernel can use to expose the
"kvmtrace-metadata" defined by the kernel implementation.
The kvmtrace tool could then use that to build up the record by using one entry
for kernel defined metadata and another to add any metadata that would be
defined by kvmtrace tool itself.
what about that one:
struct metadata {
u32 kmagic; /* stores kernel defined metadata read from debugfs
entry */
u32 umagic; /* stores userspace tool defined metadata */
u32 extra; /* it is redundant, only use to fit into record. */
}
That should give us the flexibility to keep the format if we get more metadata
requirements in the future.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
-------------------------------------------------------------------------
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
