Date: Thu, 27 Apr 2006 05:22:53 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> 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: <20060427045314.C1064@epsplex.bde.org> In-Reply-To: <20060426.101245.90994186.imp@bsdimp.com> References: <20060426103623.M1847@epsplex.bde.org> <20060425223519.F65802@ns1.feral.com> <444F0923.8050508@samsco.org> <20060426.101245.90994186.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060427045314.C1064>