Date: Thu, 27 Apr 2006 07:13:12 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> 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 Message-ID: <20060427060557.H1366@epsplex.bde.org> In-Reply-To: <20060426.134318.110812223.imp@bsdimp.com> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060427045314.C1064@epsplex.bde.org> <20060426.134318.110812223.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Apr 2006, M. Warner Losh wrote:
> In message: <20060427045314.C1064@epsplex.bde.org>
> Bruce Evans <bde@zeta.org.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060427060557.H1366>