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

[Nathan Whitehorn]

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.
-Nathan