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

[David Miller <davem@davemloft.net>]

From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Thu, 3 Nov 2016 16:41:13 -0200

> On 03/11/2016 15:22, David Miller wrote:
>> From: Torvald Riegel <triegel@redhat.com>
>> Date: Thu, 03 Nov 2016 16:39:21 +0100
>> 
>>> Is there any difference between the additional CAS on a v8 and the CAS
>>> on a v9?  If there should be none (eg, same instruciton encoding etc.),
>>> we wouldn't need a runtime check for this, would we?
>> 
>> A quick look at binutils shows that the encoding appears to be the same.
>> 
>>> That depends on whether we want to support sparc HW that does have a
>>> CAS.  It's still not clear to me whether this is a goal, and if it's a
>>> goal, whether it's a goal for today or for some time in the future.
>> 
>> I think there is value in supporting pure-v8, however painful it may
>> be.
>> 
>> I personally don't like to see when we drop support for old systems on
>> the floor just because it's too inconvenient or cumbersome to keep
>> them working properly.
> 
> In fact I see it should be one of the main reason for dropping support 
> for old system.  At least for current topic, it means add complete
> separate implementation for only one arch, where current work is
> aimed exactly to avoid it.  It is more code to audit/test on very
> specific environments and adds more complexity while fixing the
> default implementation (should the patch touch as well the arch
> specific parts or just let it broke?).

But the person creating this generic infrastructure was not asked to
fail to accomodate properly architectures such as sparc v8 when
implementing this "generic" solution, but that's what happened right?

So the blame is on both sides.

I'd feel extremely remiss as an architecture maintainer if simply
because someone can't come up with a proper generic mechanism to
implement something, my platform might be on the chopping block.

Is that really the kind of policy we want to have?