From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data. Date: Fri, 01 Dec 2006 18:37:28 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap , Mark Williamson Cc: xen-devel@lists.xensource.com, Keir Fraser , Tony Breeds List-Id: xen-devel@lists.xenproject.org On 1/12/06 5:54 pm, "George Dunlap" 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