svn commit: r217330 - head/sys/x86/x86
John Baldwin
jhb at freebsd.org
Fri Jan 14 13:20:12 UTC 2011
On Thursday, January 13, 2011 5:12:47 pm Warner Losh wrote:
> On 01/12/2011 17:06, Bruce Evans wrote:
> > On Wed, 12 Jan 2011, John Baldwin wrote:
> >
> >>> Log:
> >>> Fix a brain fart. Since this file is shared between i386 and
> >>> amd64, a
> >>> bus_size_t may be 32 or 64 bits. Change the bounce_zone alignment
> >>> field
> >>> to explicitly be 32 bits, as I can't really imagine a DMA device that
> >>> needs anything close to 2GB alignment of data.
> >>
> >> Hmm, we do have devices with 4GB boundaries though. I think I'd
> >> prefer it if
> >> you instead if you did this:
> >>
> >> #if defined(amd64) || defined(PAE)
> >> #define SYSCTL_ADD_BUS_SIZE_T SYSCTL_ADD_UQUAD
> >> #else
> >> #define SYSCTL_ADD_BUS_SIZE_T SYSCTL_ADD_UINT
> >> #endif
> >>
> >> and then just used SYSCTL_ADD_BUS_SIZE_T() in the code so we could
> >> let the
> >> members in the bounce zone retain the same types passed to
> >> bus_dma_tag_create().
> >
> > U_LONG should work on all arches. malloc(9) still uses u_long instead
> > of size_t. This works for scalars even on the recently removed i386's
> > with 32-bit longs where u_long is larger than size_t, since larger is
> > a fail-safe direction. This fails for pointers. Newer parts of malloc()
> > and uma are broken unless u_long is the same as uintptr_t, since they
> > cast pointers to u_long. This direction is fail-safe too, but gcc warns
> > about it.
>
> u_long doesn't work for N32. There, the pointers may only be 32-bit,
> but PAs ar 64-bit. Longs are only 32-bits.
It doesn't work on PAE either. bus_size_t is not the same as size_t in this
case.
--
John Baldwin
More information about the svn-src-all
mailing list