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;
#else
typedef uint32_t bus_addr_t;
#endif
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
necessary vm_size_t.
Bruce
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
