Re: [kvm-ppc-devel] kvm trace support for ppc

[Hollis B. <ho...@us...>]

On Tuesday 13 May 2008 03:06:19 Tan, Li wrote:
> Hollisb,
> I have 2 more questions:
> 1. seems record won't be overwritten because current code is as following:
> /*
>  *  The relay channel is used in "no-overwrite" mode, it keeps trace of how
>  *  many times we encountered a full subbuffer, to tell user space app the
>  *  lost records there were.
>  */
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 		return 1;
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }
> 
> 2. Then needn't expose debugfs entry "kvmtrace-metadata", we can use 
existing relayfs to output struct metadata with kmagic, if we update code as 
following?
> static int kvm_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
> 				     void *prev_subbuf, size_t prev_padding)
> {
> 	struct kvm_trace *kt;
> 
> 	if (!relay_buf_full(buf))
> 	{
> 		if (!prev_subbuf) {
> 			//here is executed only once (when the channel is opened)
> 			subbuf_start_reserve(buf, sizeof(struct metadata));
> 			((struct metadata *)subbuf)->kmagic = 0x1234;
> 		}
> 		
> 		return 1;
> 	}
> 
> 	kt = buf->chan->private_data;
> 	atomic_inc(&kt->lost_records);
> 
> 	return 0;
> }

Ah, I didn't understand what the "lost records" handling was about. Given that 
it won't be lost, it would be OK for the kernel to export the header, and in 
that case I guess you would want it to be the same size as the other records. 
I'm not sure how I feel about that from a layering point of view, but at 
least it would be functional.

-- 
Hollis Blanchard
IBM Linux Technology Center