Re: [kvm-ppc-devel] [PATCH 1/5]Add some trace markers and exposeinterfaces in kernel for tracing

[Hollis Blanchard <hollisb@us.ibm.com>]

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