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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 03/11/2016 18:33, 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?

That was not really what happened, for this specific case the new
pthread_barrier was added to fix a race condition issue (BZ#13065)
and first patch version was sent about 1 year ago [1] and Torvald's
explicit asked you what would a better solution for sparc32 at time.
He ping again before 2.23 release [2] about four months later.

Since we got not reply about sparc32, I, as release manager for
2.23, decided that best course of action was to emit an build
error [3].

Now, I am fully aware that you or any other sparc mantainer
or developer might not had the time back then to create a
working implementation in time.  Neither we are asking for
it.

However, I think we need to set proper plan for this specific
issue and that was my point of this email.  What I think would 
be a good approach was to know what kind of plan you had for the
specific issue back then:

  * Issue build error?
  * Create dummy atomic operation that would result in build 
    success, but potentially runtime failures?
  * Continue to use the old implementation and carry BZ#13065
    on sparc?
  * Implement the kernel atomic kernel primitives?

And I suggested to remove sparc-v8 just because I saw no movement
on trying to at least re-enable its build.  Also, answering your
questioning, the idea is not to make you fix all the underlying
issues on your maintained platform, bur rather help us decide 
what would be better for such cases.  However for that, we will
need your input.  

And If you check on release wiki [4], lot of platforms have various
unsolved issues, but that's not the case to just chomp down then.

[1] https://sourceware.org/ml/libc-alpha/2015-07/msg00585.html
[2] https://sourceware.org/ml/libc-alpha/2015-12/msg00484.html
[3] https://www.sourceware.org/ml/libc-alpha/2016-01/msg00338.html
[4] https://sourceware.org/glibc/wiki/Release/2.24