cvs commit: src/sys/dev/bce if_bcereg.h
bde at zeta.org.au
Wed Apr 26 00:48:34 UTC 2006
On Tue, 25 Apr 2006, Scott Long wrote:
> Warner Losh wrote:
>> The problem is that PAE's bus_size_t is a 32-bit quantity, when it
>> should be a 64-bit quantity:
>> #ifdef PAE
>> typedef uint64_t bus_addr_t;
>> typedef uint32_t bus_addr_t;
>> typedef uint32_t bus_size_t;
No, it should be a 32-bit quantity like it is.
> The next problem is that the boundary argument of bus_dma_tag_create()
> is a bus_size_t. For all PCI Express devices, you need to be able to
> stick a value of 0x100000000 (2^32) in here, have busdma do the right
> thing with it, and not have the compiler complain. I'm torn between
> declaring that the boundary is actually an address and thus should be
> declared as a bus_addr_t, and declaring that bus_size_t should be
> 64-bits on PAE just like it is on real 64-bit platforms. The right
I think the boundary is sometimes an address, so it needs to always
have the type of an address. It's never exactly a size.
> answer is probably to do both. This means a core API change to busdma
> and therefore to 90% of the hardware drivers in the tree, so it's not
> easy to justify MFC'ing it. It can be mostly worked around now anyways.
> Does this sound accurate and/or reasonable?
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
More information about the cvs-src