From owner-svn-src-head@FreeBSD.ORG Thu Jan 13 00:10:30 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1031106566B; Thu, 13 Jan 2011 00:10:30 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0248FC17; Thu, 13 Jan 2011 00:10:30 +0000 (UTC) Received: by iyb26 with SMTP id 26so1087272iyb.13 for ; Wed, 12 Jan 2011 16:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RAV0rRT2liyFbfr+lllG4JyubCxOUgbLqOkWf4JOw+0=; b=TDs0Y6lOItMlhnV2JpWk5FnWs3VAmcIr3ZfaUggN/I051xtDl0f6WBiYsRasZeUaJq NXMa0XZNs8AOjbdzWE1sPHdSr3+qC3WDocWhr+xesG72IAlnxmPD89snUX3fqPsy5F6r bL+nyqe4saVVwoecIzZGkYaKtcfvOIZxxJkVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vID1x2W8DGFUCArHcWGAUhtYZjpaEBz+XJeJ3F4uTLgb30++fU/ep3uQ1Gg+7N4jNc +JBOQgaHcbjJzmRPcvKTRomFQgUBeU4thC5FOP+x0tqZYDSs0NI4wVic4bFcopGvkr9g qySL+K7E/xIzCt3gzKszhvm5hZrSfRH/PMVNs= MIME-Version: 1.0 Received: by 10.231.171.197 with SMTP id i5mr1750449ibz.54.1294877429772; Wed, 12 Jan 2011 16:10:29 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.160.147 with HTTP; Wed, 12 Jan 2011 16:10:29 -0800 (PST) In-Reply-To: <20110113104728.L1003@besplex.bde.org> References: <201101122108.p0CL8o3Q012038@svn.freebsd.org> <201101121621.30371.jhb@freebsd.org> <20110113104728.L1003@besplex.bde.org> Date: Wed, 12 Jan 2011 16:10:29 -0800 X-Google-Sender-Auth: yncRQz0xW6gZV7dDYaqnvwnIfE8 Message-ID: From: mdf@FreeBSD.org To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r217330 - head/sys/x86/x86 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:10:30 -0000 On Wed, Jan 12, 2011 at 4:06 PM, Bruce Evans wrote: > On Wed, 12 Jan 2011, John Baldwin wrote: > >>> Log: >>> =A0Fix a brain fart. =A0Since this file is shared between i386 and amd6= 4, a >>> =A0bus_size_t may be 32 or 64 bits. =A0Change the bounce_zone alignment= field >>> =A0to explicitly be 32 bits, as I can't really imagine a DMA device tha= t >>> =A0needs anything close to 2GB alignment of data. >> >> Hmm, we do have devices with 4GB boundaries though. =A0I think I'd prefe= r it >> if >> you instead if you did this: >> >> #if defined(amd64) || defined(PAE) >> #define SYSCTL_ADD_BUS_SIZE_T =A0 =A0 =A0 =A0 =A0 SYSCTL_ADD_UQUAD >> #else >> #define SYSCTL_ADD_BUS_SIZE_T =A0 =A0 =A0 =A0 =A0 SYSCTL_ADD_UINT >> #endif >> >> and then just used SYSCTL_ADD_BUS_SIZE_T() in the code so we could let t= he >> 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 mall= oc() > 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 warn= s > 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. =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. Thanks, matthew