From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtM6r-0000hx-LG for qemu-devel@nongnu.org; Thu, 01 Oct 2009 09:54:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtM6n-0000gZ-Uh for qemu-devel@nongnu.org; Thu, 01 Oct 2009 09:54:17 -0400 Received: from [199.232.76.173] (port=58890 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtM6l-0000gP-TA for qemu-devel@nongnu.org; Thu, 01 Oct 2009 09:54:12 -0400 Received: from mail-px0-f179.google.com ([209.85.216.179]:42137) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtM6l-0005FM-OM for qemu-devel@nongnu.org; Thu, 01 Oct 2009 09:54:11 -0400 Received: by pxi9 with SMTP id 9so160270pxi.4 for ; Thu, 01 Oct 2009 06:54:10 -0700 (PDT) Message-ID: <4AC4B47E.5010309@codemonkey.ws> Date: Thu, 01 Oct 2009 08:54:06 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4/9] pci: use uint64_t for bar addr and size instead of uint32_t. 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> <20091001053302.GA3317@redhat.com> In-Reply-To: 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: malc Cc: Isaku Yamahata , qemu-devel@nongnu.org, "Michael S. Tsirkin" malc wrote: > I don't understand this at all. POSIX says that if you include any of > it's headers be prepared to deal with it, i.e. any of your own > typedefs that end with _t are potentially clashing with what's defined > there, similarly identifiers that start with 'str', 'E', double > underscore and underscore followed by a capital letter are reserved by > C, you just don't go there. > _t is used pervasively throughout the code right now. In particular, we have ram_addr_t and target_phys_addr_t. pci_addr_t is a logical addition. I do agree that adhering to Posix is a good thing, but I think either we have to go through and fixup all of the _t's in the code today, or just accept the fact that we don't strictly adhere to Posix and deal with it if we ever have to. The middle ground where we don't allow new uses of _t but keep the old ones is just going to result in mass confusion and bike shedding. Regards, Anthony Liguori