From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73568 invoked by alias); 2 Nov 2016 11:29:35 -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 73508 invoked by uid 89); 2 Nov 2016 11:29:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Hx-languages-length:2684, H*F:U*andreas, 2016-11-02 X-HELO: mx2.bahnhof.se X-Spam-Score: 0.664 Message-ID: <5819CE00.5020308@gaisler.com> Date: Wed, 02 Nov 2016 11:29:00 -0000 From: Andreas Larsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Torvald Riegel , David Miller CC: libc-alpha@sourceware.org, adhemerval.zanella@linaro.org, carlos@redhat.com, software@gaisler.com Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware References: <1478015984.7146.645.camel@localhost.localdomain> <20161101.120933.844037675386229627.davem@davemloft.net> <1478018801.7146.655.camel@localhost.localdomain> <20161101.125117.2228115672691137607.davem@davemloft.net> <1478081121.7146.673.camel@localhost.localdomain> In-Reply-To: <1478081121.7146.673.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00052.txt.bz2 On 2016-11-02 11:05, Torvald Riegel wrote: > On Tue, 2016-11-01 at 12:51 -0400, David Miller wrote: >> From: Torvald Riegel >> Date: Tue, 01 Nov 2016 17:46:41 +0100 >> >>> On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote: >>>> From: Torvald Riegel >>>> Date: Tue, 01 Nov 2016 16:59:44 +0100 >>>> >>>>> On Tue, 2016-11-01 at 16:07 +0100, Andreas Larsson wrote: >>>>>> Any comments are most welcome. The spin lock based sparcv8 semaphore >>>>>> implementation is currently unchanged by this patchset, but I would say >>>>>> that that should go as well. >>>>> >>>>> Agreed. >>>> >>>> I think tossing out all of the ldstub based v8 code is not wise. >>>> >>>> I was envisioning adding code to use ldstub on v8 when CAS is not >>>> available in order to maintain the status quo of what worked and >>>> was functional before the changes which introduced this problem >>>> for v8 in the first place. >>>> >>>> Having that in place until the kernel-side atomics could be >>>> implemented, propagated, and supported in glibc would be a nice >>>> intermediate state compared to what we have now. >>> >>> How do you intend to make the synchronization primitives work whose >>> implementation requires a CAS and for which nobody has provided an >>> alternative implementation that does not require CAS? >> >> The pure userland version will do what has been done for decades, >> by using a spinlock that protects the word we want to do atomic >> operations upon. A hash table of spinlocks is another option. > > I know about the available techniques; my question was rather aimed at > who's going to do the work, in which rough stages, and when. > > An external table of locks does not work for process-shared > synchronization. Do you plan to not support that, and abort() when > someone tries to create a process-shared condvar, for example? > > Or do you intend to write sparc-specific versions of all the concurrent > data structures that are process-shared? Note that in the new condvar, > for example, there's no unused space in pthread_cond_t that could be > used for a spinlock. So you'd have to reorganize quite a bit. > > If you want sparc-specific versions, who's going to implement them, and > when? What do we do in the meantime? [resent due to failure on my part to remove standard signature] Linux kernel commit 8b30ca73b7cc7f2177cfc4e8274d2ebdba328cd5 added sys_sendmsg and sys_recvmsg to the sys_call_table in arch/sparc/kernel/systbls_32.S. So sparc32 kernels prior to Linux 4.4 do not support them as straight up system calls. Best regards, Andreas Larsson