Hollis Blanchard wrote:
> On Sunday 20 April 2008 00:38:32 Liu, Eric E wrote:
>> 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. */
>> }
>
> So you've gone back to the idea about the kernel inserting a special
> trace record? How do you handle the case where this record is
> overwritten before the logging app gets a chance to extract it? This
> issue is why I would prefer Christian's idea of a separate debugfs
> file (*not* relay channel) to export kernel flags.
>
Yes, seems my original idea not a good one, I agree with you and
Christian.
> At that point, kvmtrace can insert the flags in any way it wants. It
> doesn't need to appear as a trace record at all; it should simply be
> a header at the beginning of the trace file.
-------------------------------------------------------------------------
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
