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>
index | next in thread | previous in thread | raw e-mail
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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110113104728.L1003>