Date: Sun, 08 May 2011 09:47:02 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <4DC6ACE6.2090609@freebsd.org> In-Reply-To: <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com> References: <201105080039.p480doiZ021493@svn.freebsd.org> <20110508202725.K1192@besplex.bde.org> <BANLkTim_kNZJZxVe1%2BWFPjL5-4oVUORo1Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/08/11 09:44, Attilio Rao wrote: > 2011/5/8 Bruce Evans<brde@optusnet.com.au>: >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DC6ACE6.2090609>