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