cvs commit: src/sys/dev/bce if_bcereg.h

[M. Warner Losh]

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.

Warner