From owner-svn-src-projects@FreeBSD.ORG Sun May 8 15:11:15 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 4506A1065673; Sun, 8 May 2011 15:11:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0C48FC12; Sun, 8 May 2011 15:11:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 1EFAB582C0; Sun, 8 May 2011 09:47:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id qCZ6SgPRNIgT; Sun, 8 May 2011 09:47:04 -0500 (CDT) Received: from wanderer.tachypleus.net (unknown [76.210.65.155]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 74CFF582A6; Sun, 8 May 2011 09:47:03 -0500 (CDT) Message-ID: <4DC6ACE6.2090609@freebsd.org> Date: Sun, 08 May 2011 09:47:02 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110317 Thunderbird/3.1.9 MIME-Version: 1.0 To: Attilio Rao References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 15:11:15 -0000 On 05/08/11 09:44, Attilio Rao wrote: > 2011/5/8 Bruce Evans: >> On Sun, 8 May 2011, Attilio Rao wrote: >> >>> Log: >>> All architectures define the size-bounded types (uint32_t, uint64_t, >>> etc.) >>> starting from base C types (int, long, etc). >>> That is also reflected when building atomic operations, as the >>> size-bounded types are built from the base C types. >>> >>> However, powerpc does the inverse thing, leading to a serie of nasty >> >> I think you mean that it does the inverse thing for atomic ops only. >> >>> bugs. >>> Cleanup the atomic implementation by defining as base the base C type >>> version and depending on them, appropriately. >> >> I think that it is mostly the other arches that are backwards here, >> except for plain ints. MI code cannot use atomic ops for anything >> except plain ints, since no other type is guaranteed to be supported >> by the MD code. For 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 One thing I'd like to point out about your patch (which Andreas already mentioned) is that it disconnects atomic_*_long operations on 32-bit PPC, making them undefined. Since long is also a 32-bit type like int on these systems, the 32-bit kernel does in fact support this. > The following should just be used in specific MD code or be totally unsupported: > - _char, _short, _8 bit, _16 bit versions > > The following should just be used in MD code: > - _64 bit version One other unrelated comment here: ZFS requires 64-bit atomics, so we already don't have this situation, sadly. -Nathan