From owner-cvs-src@FreeBSD.ORG Wed Apr 26 19:45:12 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F61316A404; Wed, 26 Apr 2006 19:45:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F4FF43D45; Wed, 26 Apr 2006 19:45:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k3QJh4h5041241; Wed, 26 Apr 2006 13:43:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 26 Apr 2006 13:43:18 -0600 (MDT) Message-Id: <20060426.134318.110812223.imp@bsdimp.com> To: bde@zeta.org.au From: "M. Warner Losh" In-Reply-To: <20060427045314.C1064@epsplex.bde.org> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060427045314.C1064@epsplex.bde.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 19:45:12 -0000 In message: <20060427045314.C1064@epsplex.bde.org> Bruce Evans writes: : 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. In the PCI 64-bit address space, objects can be larger than 32-bits in the 2 DWORD bars. To support these large allocations, bus_space_t needs to be 64-bit. While few (if any) devices today have such large allocations, it is allowed in the 2.2 PCI standard (and subsequent revisions). Warner