From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQTC6-0008LQ-Ev for qemu-devel@nongnu.org; Mon, 13 Jul 2009 17:36:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQTC0-0008Kh-Uo for qemu-devel@nongnu.org; Mon, 13 Jul 2009 17:36:17 -0400 Received: from [199.232.76.173] (port=52657 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQTC0-0008Ke-PJ for qemu-devel@nongnu.org; Mon, 13 Jul 2009 17:36:12 -0400 Received: from mail-qy0-f174.google.com ([209.85.221.174]:32937) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQTC0-0002Mc-2n for qemu-devel@nongnu.org; Mon, 13 Jul 2009 17:36:12 -0400 Received: by qyk4 with SMTP id 4so2001904qyk.4 for ; Mon, 13 Jul 2009 14:36:11 -0700 (PDT) Message-ID: <4A5BA716.1030908@codemonkey.ws> Date: Mon, 13 Jul 2009 16:28:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int. References: <1246530731-14597-1-git-send-email-yamahata@valinux.co.jp> <1246530731-14597-7-git-send-email-yamahata@valinux.co.jp> <4A564003.5080707@codemonkey.ws> <20090710082121.GB5471@const.bordeaux.inria.fr> <20090710084508.GM12665%yamahata@valinux.co.jp> <4A573A50.1040200@codemonkey.ws> <20090713031406.GS12665%yamahata@valinux.co.jp> <4A5B8413.5080201@codemonkey.ws> <20090713211905.GA10557@miranda.arrow> In-Reply-To: <20090713211905.GA10557@miranda.arrow> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stuart Brady Cc: qemu-devel@nongnu.org Stuart Brady wrote: > On Mon, Jul 13, 2009 at 01:59:31PM -0500, Anthony Liguori wrote: > >> If so, I would think that we should use ram_addr_t for addr and then we >> can use the appropriate uintN_t type for value. Switching value like >> that though could have some subtle consequences. For instance, >> cpu_outb(env, ..., 128) would have worked properly before as would >> cpu_outb(env, ..., -32). >> > > Isn't ram_addr_t solely for return values from (and internals of) > qemu_ram_alloc() and friends? > Well it's sort of our internal address type. > Perhaps port IO addresses should have their own type? > Certainly not a bad idea but I'd still recommend typedef ram_addr_t pio_addr_t. > TBH, I'm not so sure that port IO is particularly 'special' in any way. > Right, that's why I suggested ram_addr_t. ram_addr_t is just an internal address and what we map it to is up to us. Regards, Anthony Liguori