From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Ehrhardt Subject: Re: [kvm-ppc-devel] [PATCH 1/5]Add some trace markers and exposeinterfaces in kernel for tracing Date: Fri, 18 Apr 2008 08:08:37 +0200 Message-ID: <48083AE5.5020800@linux.vnet.ibm.com> References: <9D7649D18729DE4BB2BD7B494F7FEDC2011FD35B@pdsmsx415.ccr.corp.intel.com> <200804160034.55802.hollisb@us.ibm.com> <9D7649D18729DE4BB2BD7B494F7FEDC201294778@pdsmsx415.ccr.corp.intel.com> <200804171659.34779.hollisb@us.ibm.com> <9D7649D18729DE4BB2BD7B494F7FEDC201295294@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: kvm-ppc-devel@lists.sourceforge.net, kvm-devel@lists.sourceforge.net, Hollis Blanchard To: "Liu, Eric E" Return-path: In-Reply-To: <9D7649D18729DE4BB2BD7B494F7FEDC201295294@pdsmsx415.ccr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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 everyt= hing about the data format. I think of e.g. changing kernel implementations that change endianess or ev= en 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 "k= vmtrace-metadata" defined by the kernel implementation. The kvmtrace tool could then use that to build up the record by using one e= ntry 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 metad= ata requirements in the future. -- = Gr=FCsse / regards, = Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ------------------------------------------------------------------------- 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/java= one