svn commit: r217330 - head/sys/x86/x86

[mdf at FreeBSD.org]

On Wed, Jan 12, 2011 at 4:06 PM, Bruce Evans <brde at optusnet.com.au> 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.

In this case for PAE u_long is (theoretically) too small, because a
bus_size_t is an uint64_t.

> uquad_t should never be used, like unsigned long long.  Similarly for
> signed types.  Perhaps it could be removed in sysctl interfaces first.

The name SYSCTL_ADD_UQUAD is a little misleading since it's really for
a uint64_t.  The name could be changed, but there's already plenty of
existing uses of QUAD for int64_t which aren't being changed.

Thanks,
matthew