WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fieldsfor exported xentrace data.
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8A87A9A84C201449A0C56B728ACF491E04EDF2@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C19D9E49.5A28%keir@xxxxxxxxxxxxx> <8A87A9A84C201449A0C56B728ACF491E04EDF2@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>