Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware

[David Miller <davem at davemloft dot net>]

From: Torvald Riegel <triegel@redhat.com>
Date: Wed, 02 Nov 2016 23:33:03 +0100

> On Wed, 2016-11-02 at 11:32 -0400, David Miller wrote:
>> From: Torvald Riegel <triegel@redhat.com>
>> > Or do you intend to write sparc-specific versions of all the concurrent
>> > data structures that are process-shared?
>> 
>> This would be necessary anyways, if we have two modes.  One that does
>> the pure-userland code path and one that does the kernel helper code
>> path.
> 
> All the other archs that use a kernel helper for CAS don't need it.  If
> you can call the helper in the atomic operations, you won't need a new
> algorithm except if you wanted to optimize the generic one.
> 
>> Furthermore, sparc specific versions are needed in any case since we
>> have the v9 detection even in the v8 libraries.  Look at all of the
>> code that checks for v9 in the dl_hwcap mask when deciding which
>> atomic operation to use.
> 
> Or are you talking about the implementation of the atomic operations?

Just as the "are we running on a v9 chip" test is a run-time one,
whether we are running on a kernel with kernel CAS simulation support
will be run time code path check as well.

This is why we'll need sparc specific versions of the primitives, and
why it would have been the more optimal if the primitives were
abstracted to the point where we didn't have to duplicate so much
stuff privately just to pull this off.