svn commit: r221614 - projects/largeSMP/sys/powerpc/include

[Attilio Rao]

2011/5/8 Nathan Whitehorn <nwhitehorn at freebsd.org>:
> On 05/08/11 09:44, Attilio Rao wrote:
>>
>> 2011/5/8 Bruce Evans<brde at 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.

I'm wondering how is that supposed to work on 32 bit stuff then.
I really don't want to see 32 bits arch having 64-bits faking atomics
as the only right way to do that is with some sort of interlocking and
that is not really what we want about the concept of 'atomic' (a
lockless and fast primitive).

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein