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 fields fo

To: George Dunlap <dunlapg@xxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data.
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 01 Dec 2006 18:37:28 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 01 Dec 2006 10:37:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0612010954x39da520cvcef5ef0e23d843b0@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccVd8Ca/zDORIFqEduSagANk04WTA==
Thread-topic: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data.
User-agent: Microsoft-Entourage/11.2.5.060620
On 1/12/06 5:54 pm, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:

> Variable-length trace buffers would certainly be nice.  Right now, for
> some records, I'm squeezing bits into things, and just *one* more byte
> would be great... but for other records, I'm storing 4 words of 0, and
> there just doesn't seem to be any other useful information to add.
> 
> Keir, is the simpler, "one trace size fits all" method just because it
> was easier to implement originally, or is the simplicity expected to
> greatly reduce overhead and/or bugginess?  If the former, then there
> seems enough interest in making the tracing more flexible to be worth
> changing; if the latter, then we should probably chose something and
> live with it, or perhaps a compromise (i.e., two record sizes).

There's no reason not to make the trace format more flexible. There's a
question about how you represent trace points in the Xen code though, when
the format is no longer a list of fixed size integers.

 -- Keir


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

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