From owner-cvs-all@FreeBSD.ORG Wed Apr 26 19:23:01 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB5E616A402; Wed, 26 Apr 2006 19:23:01 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D8543D49; Wed, 26 Apr 2006 19:23:01 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (Postfix) with ESMTP id 316B8328504; Thu, 27 Apr 2006 05:22:59 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3QIjgVx027013; Thu, 27 Apr 2006 04:45:43 +1000 Date: Thu, 27 Apr 2006 05:22:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: "M. Warner Losh" In-Reply-To: <20060426.101245.90994186.imp@bsdimp.com> Message-ID: <20060427045314.C1064@epsplex.bde.org> References: <20060426103623.M1847@epsplex.bde.org> <20060425223519.F65802@ns1.feral.com> <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scottl@samsco.org, src-committers@FreeBSD.org, jhb@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, mj@feral.com Subject: Re: cvs commit: src/sys/dev/bce if_bcereg.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 19:23:01 -0000 On Wed, 26 Apr 2006, M. Warner Losh wrote: > In message: <444F0923.8050508@samsco.org> > Scott Long writes: > : Matthew Jacob wrote: > : > > : >> Supporting sizes >= 4G sounds unreasonable. How can a single device > : >> need or even address so much space, even on 64-bit arches? For vm, > : >> virtual memory is sort of a device, but even it is limited to 4G on > : >> 32-bit arches, and PAE on i386 isn't pessimized by using a larger than > : >> necessary vm_size_t. > : > > : > I have need to support and help people sell machines that use 32GB of > : > directly addressable memory. In fact, the EM64T cheat will shortly Such machines cannot be i386's. > : > become an embarrasment to Intel when people find out that EM64T with PAE > : > is *not* the same as Opteron (36 vs. 40). > : > > : > I'm afraid I don't understand the 'unreasonable' argument here. Linux is > : > eating your lunch today. Do you want it to eat your dessert as well? > : bus_size_t is used for things like measuring transfer segment size. > : There is little chance that Linux, Windows, FreeBSD, or any other OS > : is ever going to try to DMA more than 2^32 bytes of data in a single > : bus transaction. Maybe you could contrive a silly infiniband device > : to do it. Anyways, it has no bearing on whether the CPU, memory > : controller, or PCI buses can do 64 bit addressing. > > bus_size_t is for differences between two bus_addr_t quantities, since > it specifies the size of resources on a bus. It is also used for > transfer sizes and the like. That's why I think it should be a 64-bit > quantity: 64-bit - 64-bit = 64-bit. No it isn't (or shouldn't be). It should be for the size of individual "objects", like size_t and vm_size_t are for the size of individual objects. In C, size_t is sometimes abused for differences, but shouldn't be, and ptrdiff_t is specifically for differences; however, prtdiff_t is only required to work for differences within objects, and since it needs an extra bit for the sign but rarely has one, it rarely actually works for external differences unless the address space is constrained. In vm, addresses are confused with differences to the point where vm_addr_t doesn't exist and the basic type vm_offset_t is used for addresses. I think vm rarely needs offsets or differences except for the special case of offsets from address 0, so this is mostly a spelling error. Bruce