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

[Torvald Riegel <triegel at redhat dot com>]

On Thu, 2016-11-03 at 16:33 -0400, David Miller wrote:
> 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?

Adding to what Adhemerval said, I want to stress again that lack of
support for CAS by the hardware or the kernel is a *serious* problem for
anything synchronization-related, especially if one wants to support
process-shared synchronization.  IMO, expecting availability of CAS is
something completely reasonable, and I don't see how concurrent code
that relies on CAS could get considered to not be sufficiently generic.

I would also categorize support for CAS as something that arch
maintainers should take care of.  I have repeatedly brought up this
topic on libc-alpha and made suggestions for how arch maintainers could
take care of it.  I'm not aware of any improvement of the situation on
the sparcv8 side (until Andreas' recent work); have I missed anything?

Also, it's not true that the only solution we offered was to fully
remove sparcv8 support.  You could just choose to not support
process-shared synchronization, for example.