Christian Ehrhardt wrote:
> 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. 

Yes, maybe we need metadata to indicate the changing kernel
implementations in the future, but adding debugfs entry seems not a good
approach. What about defining a similar metadat in kernel rather than in
userland and write it in rchan at the first time we add trace data. Then
we don't need kvmtrace tool to insert the medadata again.
like this: 
        struct kvm_trace_metadata {
                u32 kmagic; /* stores kernel defined metadata */
                u64 extra;  /* use to fit into record. */
        }
 
 

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