From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76168 invoked by alias); 3 Nov 2016 21:29:12 -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 76131 invoked by uid 89); 3 Nov 2016 21:29:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=movement, accomodate, adhemervalzanellalinaroorg, remiss X-HELO: mail-vk0-f45.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jvn8i3GMs7L8gSVIhSZo4I5ZqADnRHK2shtGwahR6MU=; b=Th6gyEWH7jOdk/B4JeWacMqmQ7MKFZOgzR2MOdU4A7ulZ1k5QBUcA1aozaRD5h9SAm 18ZvrXXdzTWO/WIIUK/2VIAP+Y3/jZJkPOjKu/gioyNn0/Guk9/IKVZUIcWeJ3tNhmBi uTeMISwMRW2PjDtAbJbkKdbPBy4dHcO34xcA33dmjJlDk0xjon8pimbQulL4q1n0Qkvp UEYXTfWrAkkPpMEOJqxknzgfMdixO8ILrb5h2Ix9pWSahF5nCzHtIFni73c85ByfrO8c vV/zvYKPpOU/VbwGAL86o60iJm8dBlFDHPuTW0QtV2NukIIfEQlbM6RxTD7iUo2dunvp uRhg== X-Gm-Message-State: ABUngveONTeBvgQHdZguq9ZYTOXpRyNqoDvKyW57yDHAus5VKQoh5nycC1q5IW+CLyAQ+o+K X-Received: by 10.31.210.130 with SMTP id j124mr9415052vkg.17.1478208539239; Thu, 03 Nov 2016 14:28:59 -0700 (PDT) Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware To: David Miller References: <1478187561.7146.742.camel@localhost.localdomain> <20161103.132213.598669006383889263.davem@davemloft.net> <20161103.163318.2291021080983591290.davem@davemloft.net> Cc: triegel@redhat.com, andreas@gaisler.com, libc-alpha@sourceware.org, carlos@redhat.com, software@gaisler.com From: Adhemerval Zanella Message-ID: Date: Thu, 03 Nov 2016 21:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161103.163318.2291021080983591290.davem@davemloft.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00123.txt.bz2 On 03/11/2016 18:33, 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? 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