From owner-svn-src-projects@FreeBSD.ORG Sun May 8 16:17:35 2011 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE4B1065674; Sun, 8 May 2011 16:17:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id A0B908FC18; Sun, 8 May 2011 16:17:34 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p48GHVb0017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 02:17:32 +1000 Date: Mon, 9 May 2011 02:17:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Attilio Rao In-Reply-To: Message-ID: <20110509020034.E2292@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1450297231-1304871451=:2292" Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2011 16:17:35 -0000 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-1450297231-1304871451=:2292 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 8 May 2011, Attilio Rao wrote: > 2011/5/8 Bruce Evans : >> >> I think that it is mostly the other arches that are backwards here, >> except for plain ints. =C2=A0MI code cannot use atomic ops for anything >> except plain ints, since no other type is guaranteed to be supported >> by the MD code. =C2=A0For example, sparc64 doesn't support any 8-bit or >> 16-bit types, and i386 doesn't support any 64-bit types (until recently; >> it now uses cmpxchg8b on some CPUs and a hack on other CPUs to support >> 64, bit types), and my version of i386 doesn't support any 8-bit or >> 16-bit types or long since these types are unusable in MI code and >> unused in MD code (long is misused in some MI code but I don't use >> such broken code). > > I want to comment specifically on this. > I think you are right and that over time our kernel policy on atomic > has got very flakey. > My personal idea is that MI part should support only this: > - _int version > - _32 bit version > - _ptr version > > and the common sense also mandates it could support easilly: > - _long version > > The following should just be used in specific MD code or be totally unsup= ported: > - _char, _short, _8 bit, _16 bit versions > > The following should just be used in MD code: > - _64 bit version This agrees exactly with my policy, except I think 64-bit types should be prepared for, and supported when it is easy (about the same as long if longs are 64 bits). atomic(9) agrees with this for the _char, _short, _8 bit, _16 bit versions. It disagrees for: - unsigned long: says that full support is always available. Correct, but inhibits expanding long. - uint64_t: says that full support is always available. Was just wrong on i386 until recently. i386 now has support for load/store only. Apparently still just wrong for powerpc32. Bruce --0-1450297231-1304871451=:2292--