From owner-cvs-all@FreeBSD.ORG Wed Apr 26 21:13:19 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 9459516A408; Wed, 26 Apr 2006 21:13:19 +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 92E8043D55; Wed, 26 Apr 2006 21:13:18 +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 44B8D328D54; Thu, 27 Apr 2006 07:13:17 +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 k3QKa0S8005606; Thu, 27 Apr 2006 06:36:01 +1000 Date: Thu, 27 Apr 2006 07:13:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: "M. Warner Losh" In-Reply-To: <20060426.134318.110812223.imp@bsdimp.com> Message-ID: <20060427060557.H1366@epsplex.bde.org> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060427045314.C1064@epsplex.bde.org> <20060426.134318.110812223.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 21:13:19 -0000 On Wed, 26 Apr 2006, M. Warner Losh wrote: > In message: <20060427045314.C1064@epsplex.bde.org> > Bruce Evans writes: > : On Wed, 26 Apr 2006, M. Warner Losh wrote: > : > 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 > : ... > 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 ^^^^^^^doesn't exist > 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). Hmm, there is some confusion, both in my head and in the code, between physical addresses and virtual addresses. E.g., in i386/include/bus.h, only the memory-mapped and i/o mapped access methods are supported, so all directly addressable device addresses fit in 32 bits for the memory-mapped case and in 16 bits for the i/o mapped case. The directly addressable addresses are handled well by not using bus_addr_t for them -- bus_handle_t (= u_int) is used. The offsets from these addresses are handled not so well by using bus_size_t for them. These offsets are not even sizes, and are much more constrained than physical device sizes. There is a fundamental assumption that the whole "object" can be mapped into (a small piece of) virtual memory. DMA is closer to the hardware and has quite different constraints so perhaps it should use different types. It already uses bus_addr_t without going through bus_handle_t, and has different confusion for bus_size_t. BTW, no one cares that functions like read(2) are limited to returning INT_MAX bytes even on 64-bit arches, mainly because the kernel still doesn't understand the 20 year old userland type ssize_t that sort of corresponds to bus_size_t (syscalls.master says ssize_t read(), but this is just a type mismatch with sys_generic.c:read()). Bruce