From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtEJy-0002OE-6S for qemu-devel@nongnu.org; Thu, 01 Oct 2009 01:35:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtEJt-0002Kk-Hn for qemu-devel@nongnu.org; Thu, 01 Oct 2009 01:35:17 -0400 Received: from [199.232.76.173] (port=58522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtEJt-0002Kc-2q for qemu-devel@nongnu.org; Thu, 01 Oct 2009 01:35:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53263) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtEJs-0002oK-FP for qemu-devel@nongnu.org; Thu, 01 Oct 2009 01:35:12 -0400 Date: Thu, 1 Oct 2009 07:33:02 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size instead of uint32_t. Message-ID: <20091001053302.GA3317@redhat.com> References: <1247656509-32227-1-git-send-email-yamahata@valinux.co.jp> <1247656509-32227-5-git-send-email-yamahata@valinux.co.jp> <20090930114122.GG18802@redhat.com> <20090930161547.GB21595@redhat.com> <20090930172641.GA28300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Isaku Yamahata , qemu-devel@nongnu.org On Wed, Sep 30, 2009 at 09:59:11PM +0400, malc wrote: > On Wed, 30 Sep 2009, Michael S. Tsirkin wrote: > > > On Wed, Sep 30, 2009 at 08:51:02PM +0400, malc wrote: > > > On Wed, 30 Sep 2009, Michael S. Tsirkin wrote: > > > > > > > On Wed, Sep 30, 2009 at 07:25:45PM +0400, malc wrote: > > > > > On Wed, 30 Sep 2009, Michael S. Tsirkin wrote: > > > > > > > > > > > On Wed, Jul 15, 2009 at 08:15:04PM +0900, Isaku Yamahata wrote: > > > > > > > This patch is preliminary for 64bit bar. > > > > > > > For 64bit bar support, replace uint32_t with uint64_t for addr/size > > > > > > > to be able to represent 64bit width. > > > > > > > > > > > > > > Signed-off-by: Isaku Yamahata > > > > > > > > > > > > As long as we are touching all code: what do you think about > > > > > > typedef uint64_t pcibus_t; > > > > > > so that will be easier to find later? > > > > > > > > > > Please read the CODING_STYLE on the subject of _t suffix. > > > > > > > > > > [..snip..] > > > > > > > > What do you refer to? > > > > > > > > > > _t suffix is reserved by POSIX. > > > > There's still no better naming for scalars. Worst case some platform > > will fail to compile, and we'll rename. > > > > Not good enough, if you are using something you have to abide the > constraints. So, posix does not reserve all of *_t namespace, it would negate years of C code. It simply says posix implementations can add only symbols ending with _t in the headers: this is a constraint on posix headers, not on applications that use them. Thus you have to find some other means to avoid conflict if you have symbols ending with _t. Using your module name as a prefix is a classical way to do this, for pci prefixing type name with pci_ should be enough to prevent any issues. > -- > mailto:av1474@comtv.ru