From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQQkb-0006CH-Qh for qemu-devel@nongnu.org; Mon, 13 Jul 2009 14:59:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQQkX-0006C5-DZ for qemu-devel@nongnu.org; Mon, 13 Jul 2009 14:59:45 -0400 Received: from [199.232.76.173] (port=53017 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQQkX-0006C2-9t for qemu-devel@nongnu.org; Mon, 13 Jul 2009 14:59:41 -0400 Received: from mx20.gnu.org ([199.232.41.8]:8600) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MQQkW-0002Lh-H1 for qemu-devel@nongnu.org; Mon, 13 Jul 2009 14:59:40 -0400 Received: from rv-out-0708.google.com ([209.85.198.245]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQQkV-0007hg-FS for qemu-devel@nongnu.org; Mon, 13 Jul 2009 14:59:39 -0400 Received: by rv-out-0708.google.com with SMTP id b17so597063rvf.22 for ; Mon, 13 Jul 2009 11:59:37 -0700 (PDT) Message-ID: <4A5B8413.5080201@codemonkey.ws> Date: Mon, 13 Jul 2009 13:59:31 -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> In-Reply-To: <20090713031406.GS12665%yamahata@valinux.co.jp> 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: Isaku Yamahata Cc: Tristan Gingold , Samuel Thibault , qemu-devel@nongnu.org Isaku Yamahata wrote: > On Fri, Jul 10, 2009 at 07:55:44AM -0500, Anthony Liguori wrote: > >> Isaku Yamahata wrote: >> >>> Then, the signatures should like the followings? >>> >>> void cpu_out[bwl](CPUState *env, int64_t addr, int{8, 16, 32}_t val); >>> uint{8, 16, 32}_t cpu_inw(CPUState *env, int16_t addr); >>> >>> >> If anything, it ought to be: >> >> void cpu_out[bwl](CPUState *env, uint16_t addr, int{8, 16, 32}_t val); >> >> But it's int today because the assumption is that most architectures can >> more efficiently pass int than other types (because it's the native >> type) and that int is adequate to contain all of the necessary types. >> >> But my original question still remains, what's the motivation for this >> change? >> > > Yes, the patch description too terse. > The motivation is to remove inconsistency with the other part of > qemu. > > - Using int for cpu_{in, out}[bwl] is inconsistent with other part. > For address or value, uintN_t is used by other qemu part. > At least I can confirm, softmmu, CPU{Read, Write}MemoryFunc, pci, > target_phys_addr_t and the callers of cpu_{in, out}[bwl](). > What does the PCI spec say about the size of PIO IO regions? Can they be as large as MEM IO regions? 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). Regards, Anthony Liguori