Date: Thu, 13 Jan 2011 13:53:57 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: mdf@FreeBSD.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r217330 - head/sys/x86/x86 Message-ID: <20110113132935.A1458@besplex.bde.org> In-Reply-To: <AANLkTi=ub6-r977Jag3Lt3wdauw1dQaBvGv7TpMu3L-s@mail.gmail.com> References: <201101122108.p0CL8o3Q012038@svn.freebsd.org> <201101121621.30371.jhb@freebsd.org> <20110113104728.L1003@besplex.bde.org> <AANLkTi=ub6-r977Jag3Lt3wdauw1dQaBvGv7TpMu3L-s@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1264095000-1294887237=:1458 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 12 Jan 2011 mdf@FreeBSD.org wrote: > On Wed, Jan 12, 2011 at 4:06 PM, Bruce Evans <brde@optusnet.com.au> wrote= : >> On Wed, 12 Jan 2011, John Baldwin wrote: >>> ... >>> 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. =A0malloc(9) still uses u_long instead >> of size_t. =A0This 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. =A0This fails for pointers. =A0Newer parts of mal= loc() >> and uma are broken unless u_long is the same as uintptr_t, since they >> cast pointers to u_long. =A0This direction is fail-safe too, but gcc war= ns >> about it. > > In this case for PAE u_long is (theoretically) too small, because a > bus_size_t is an uint64_t. Lucky there is no BUS_SIZE_MAX to complicate recent changes to <limits.h> :-). >> uquad_t should never be used, like unsigned long long. =A0Similarly for >> signed types. =A0Perhaps 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. Yes, I almost suggested changing all of these to int64_t etc. Recent changes to <limits.h> result in quad_t and its limits being assumed to be the same as int64_t on all arches, at the top level (previously this was stated to be true by MD levels, except for some broken cases where the limits had type long long but int64_t has type long). quad_t must be precisely 64 bits 2's complement with no padding to work. int64_t must be the same to meet its spec. Now I seem to remember that sysctl() users are the largest user of quad_t's (since sysctl never supported int64_t or intmax_t). It would be easy to change all its quads to int64's since these types must be essentially the same to work. But as you know too well, there are now an enormous number of sysctls to change from [U]QUAD to [U]INT64. This despite CTLTYPE_QUAD being unused between at least 4.4BSD-Lite2 and FreeBSD-3, and being broken in sysctl(8) between FreeBSD-4 and ~2007. I tried to kill quads and long longs 10-15 years ago because they were about to be superseded by initmax_t, but of course they are used much more now :-(. Bruce --0-1264095000-1294887237=:1458--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110113132935.A1458>