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