cvs commit: src/sys/dev/bce if_bcereg.h
M. Warner Losh
imp at bsdimp.com
Wed Apr 26 16:15:11 UTC 2006
In message: <444F0923.8050508 at samsco.org>
Scott Long <scottl at 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
: > 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?
: > -matt
: 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.
More information about the cvs-src