Date: Thu, 13 Jan 2011 11:06:21 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, Matthew D Fleming <mdf@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r217330 - head/sys/x86/x86 Message-ID: <20110113104728.L1003@besplex.bde.org> In-Reply-To: <201101121621.30371.jhb@freebsd.org> References: <201101122108.p0CL8o3Q012038@svn.freebsd.org> <201101121621.30371.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. uquad_t should never be used, like unsigned long long. Similarly for signed types. Perhaps it could be removed in sysctl interfaces first. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110113104728.L1003>