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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
