From owner-svn-src-projects@FreeBSD.ORG Sun May 8 14:44:05 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 95A681065672; Sun, 8 May 2011 14:44:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DA7A8FC0C; Sun, 8 May 2011 14:44:04 +0000 (UTC) Received: by yie12 with SMTP id 12so1993816yie.13 for ; Sun, 08 May 2011 07:44:04 -0700 (PDT) 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=NGRanqLS3HgfU5/R+o+Mqo+kG9L5GKqzuEbSEiEcrNQ=; b=ORp/n+mIjrYRqwSEwaLuVFqz5LY5FUABRDvPHf3wMQJ42G5QRGYc12AW86v3ia/0ts Qg1RxAzq+BBaOkAHNSP5PSFyNFJuKR7O/GtXQalEOBCKj5o40MR0JKfAkQOhXPCPZ2G3 65WBYtBGS7+zCa4KPTSlpoa1gXJzFla0rdAr4= 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=uQcyHQNjETBm1zdr/intc6V2z+cjF3IikTAJgqy65CJTok8latcxVh+lJDNFgXRY1q cOqDrby1elFJQvD3niX00fqrUo8OFzlbA5Na0a3qPGfmlMhKP48TO/9BwN4sWe/uV2Pk fcAX4vfVPeB3ZFOamUsSBvzgRZtTXL8VHQAOc= MIME-Version: 1.0 Received: by 10.236.139.233 with SMTP id c69mr6941584yhj.171.1304865844557; Sun, 08 May 2011 07:44:04 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.111.33 with HTTP; Sun, 8 May 2011 07:44:04 -0700 (PDT) In-Reply-To: <20110508202725.K1192@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> Date: Sun, 8 May 2011 10:44:04 -0400 X-Google-Sender-Auth: BStGxSwon_SC3IySNHZdx5jcTmE Message-ID: From: Attilio Rao To: Bruce Evans Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org 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 14:44:05 -0000 2011/5/8 Bruce Evans : > On Sun, 8 May 2011, Attilio Rao wrote: > >> Log: >> =C2=A0All architectures define the size-bounded types (uint32_t, uint64_= t, >> etc.) >> =C2=A0starting from base C types (int, long, etc). >> =C2=A0That is also reflected when building atomic operations, as the >> =C2=A0size-bounded types are built from the base C types. >> >> =C2=A0However, powerpc does the inverse thing, leading to a serie of nas= ty > > I think you mean that it does the inverse thing for atomic ops only. > >> =C2=A0bugs. >> =C2=A0Cleanup the atomic implementation by defining as base the base C t= ype >> =C2=A0version and depending on them, appropriately. > > 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 unsuppo= rted: - _char, _short, _8 bit, _16 bit versions The following should just be used in MD code: - _64 bit version I'm not entirely sure what would be the impact on the current kernel of this scheme, but maybe with some luck this is how it is already got. Someone interested can check that. Attilio --=20 Peace can only be achieved by understanding - A. Einstein