From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39661 invoked by alias); 3 Nov 2016 22:25:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 39641 invoked by uid 89); 3 Nov 2016 22:25:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=remiss, chopping, adhemerval.zanella@linaro.org, accomodate X-HELO: mx1.redhat.com Message-ID: <1478211936.7146.789.camel@localhost.localdomain> Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware From: Torvald Riegel To: David Miller Cc: adhemerval.zanella@linaro.org, andreas@gaisler.com, libc-alpha@sourceware.org, carlos@redhat.com, software@gaisler.com Date: Thu, 03 Nov 2016 22:25:00 -0000 In-Reply-To: <20161103.163318.2291021080983591290.davem@davemloft.net> References: <1478187561.7146.742.camel@localhost.localdomain> <20161103.132213.598669006383889263.davem@davemloft.net> <20161103.163318.2291021080983591290.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00125.txt.bz2 On Thu, 2016-11-03 at 16:33 -0400, David Miller wrote: > From: Adhemerval Zanella > Date: Thu, 3 Nov 2016 16:41:13 -0200 > > > On 03/11/2016 15:22, David Miller wrote: > >> From: Torvald Riegel > >> 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.