Date: Wed, 26 Apr 2006 13:43:18 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: bde@zeta.org.au 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: <20060426.134318.110812223.imp@bsdimp.com> In-Reply-To: <20060427045314.C1064@epsplex.bde.org> References: <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com> <20060427045314.C1064@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060427045314.C1064@epsplex.bde.org>
Bruce Evans <bde@zeta.org.au> writes:
: On Wed, 26 Apr 2006, M. Warner Losh wrote:
:
: > In message: <444F0923.8050508@samsco.org>
: > Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060426.134318.110812223.imp>