[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fieldsfor exported xentrace data.


  • To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • From: "George Dunlap" <gdunlap@xxxxxxxxxxxxx>
  • Date: Thu, 7 Dec 2006 13:25:48 -0500
  • Cc: Mark Williamson <mark.williamson@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 08 Dec 2006 01:44:55 -0800
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=o3jbhp9LAf6eBQFeCW5BuH7odUoUcMD/MnfhyFf83580ALz4tS77pQQ/W/k/gt/npsvQowOqvI/0ElTK4VrqlCiTcveUWRFd2agLu+Zx0gMGxPFi8+7Xut7qBy0u7aNtGkl7h66TINsLNiInbm0TJA1ke57w9UgeuA59lqKOJRQ=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 12/7/06, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx> wrote:
Ideally the format string would include the 'pretty print' format for
the post processing tools (e.g. put the strings as literals in a
separate segment and extract them later in the build process. That's not
attractive if we have to parse the strings at run time, though. It could
easily be fixed by pre-processing all source files with M4 or perl, but
I don't think we want to go there.

I should think that parsing the strings at runtime should be pretty
quick -- we don't have to actually make text out of them, we just need
to scan through looking for % tokens, determine the size, and copy to
the trace buffer.

We should be able to make more optimized tracing functions for hot
paths that copy data directly into the trace buffer.

Just for the record, my idea wan't that every single trace record
would have a struct associated with it.  I think that for most trace
records, a list of u32 or u64 would work just fine.  I was envisioning
a class of functions:
 trace_1d(int type, u32 val1);
 trace_2d(int type, u32 val1, u32 val2);
 /* etc */
 trace_nd(int type, int n, ...); /* Take N unsigned longs */
 trace_1l(int type, u64 val1);
 /* etc */
 trace_v(int type, size_t bytes, char *data); /* Take a struct of
size 'bytes' */

The final one would only be used in cases where layout is important,
mainly where space is critical.  An advantage of this method is that
we can use sub-byte-sized fields (e.g., 3 bits) and let the compiler
do the work of shifting things around.

If we adopt the format-string model, I suspect that in most cases, no
one is going to worry about bits anyway, but just put up "%d" (which
will probably translate to u32) even for data that only need 3 bits.

If we adopt the format-string model, we need to make sure it's
unambiguous.  For instnace, does "%lx" translate to u32 on both 32-
and 64-bit builds?  How do I specify u16 and u8?  Can I print strings?

Pretty-printing might be nice, but I plan on using the binary format
anyway for my analysis tools, so it's not that big a deal to me.

-George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.