From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60219 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OnWsL-0001gZ-5G
	for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:15:50 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OnWsG-00068f-27
	for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:15:45 -0400
Received: from mail-gx0-f173.google.com ([209.85.161.173]:43976)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OnWsF-00068N-W5
	for qemu-devel@nongnu.org; Mon, 23 Aug 2010 09:15:40 -0400
Received: by gxk5 with SMTP id 5so2269191gxk.4
	for <qemu-devel@nongnu.org>; Mon, 23 Aug 2010 06:15:39 -0700 (PDT)
Message-ID: <4C727479.4080702@codemonkey.ws>
Date: Mon, 23 Aug 2010 08:15:37 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 06/14] trace: Trace entry point of balloon
	request handler
References: <1281609395-17621-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<1281609395-17621-7-git-send-email-stefanha@linux.vnet.ibm.com>
	<4C719998.6030203@codemonkey.ws>
	<20100823101019.GB2335@stefan-thinkpad.transitives.com>
In-Reply-To: <20100823101019.GB2335@stefan-thinkpad.transitives.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Julien Desfossez <ju@klipix.org>, qemu-devel@nongnu.org, Prerna Saxena <prerna@linux.vnet.ibm.com>

On 08/23/2010 05:10 AM, Stefan Hajnoczi wrote:
> On Sun, Aug 22, 2010 at 04:41:44PM -0500, Anthony Liguori wrote:
>    
>> ram_addr_t is not necessarily an unsigned long.  It's actually a
>> uint64_t.   Integer promotion should handle this in most cases but
>> having the definition in two different places worries me a bit.
>>      
> I thought it is unsigned long:
>
> cpu-common.h:typedef unsigned long ram_addr_t;
>    

Yeah, the definition has changed I think so you're right.

> ram_addr_t cannot be used explicitly because it is only defined for
> softmmu targets.  User-only builds do not define ram_addr_t and the
> generated trace.h header would break the compile.
>
> This is a more general weakness of the tracing system: it is fragile
> under #ifdefed builds because it tries to work for softmmu, user-only,
> and qemu-tools!  Perhaps we should split the trace-events file.
>    

I think documentation could go a long way to addressing this.

Regards,

Anthony Liguori

> Stefan
>