This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Testing glibc 2.24 on remaining machines.
- From: Torvald Riegel <triegel at redhat dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: carlos at redhat dot com, libc-alpha at sourceware dot org, rth at redhat dot com, samuel dot thibault at ens-lyon dot org, hjl dot tools at gmail dot com, vapier at gentoo dot org, schwab at suse dot de, chunglin_tang at mentor dot com, adhemerval dot zanella at linaro dot org
- Date: Thu, 21 Jul 2016 13:32:48 +0200
- Subject: Re: Testing glibc 2.24 on remaining machines.
- Authentication-results: sourceware.org; auth=none
- References: <521d3f7a-6375-11c7-5987-ad2f0f1ab290@redhat.com> <20160720.153931.575029361394679476.davem@davemloft.net>
On Wed, 2016-07-20 at 15:39 -0700, David Miller wrote:
> From: Carlos O'Donell <carlos@redhat.com>
> Date: Sat, 16 Jul 2016 14:11:27 -0400
>
> > Are you able to do the sparc and sparc64 testing?
>
> I did v9 sparc and sparc64 runs and they mostly look fine.
Great, thanks.
What do we do with pre-v9 sparc though? I believe pthreads barriers
don't work on it currently, and the new condvar and rwlock
implementaitons that we'll hopefully switch to in the next cycle also
wouldn't work on pre-v9 sparc.
Do we want to:
(1) not further support pre-v9 sparc?
(2) not further support all of pthreads on pre-v9 sparc (and potentially
other things in glibc that use rwlocks, IIRC we don't use condvars
internally)?
(3) build something that emulates full C11 atomics, either backed by
locks in the synchronization data structure or a process-global lock
array (though we'd have to adapt the current condvar because there's no
space for an extra lock there)?
We could also continue to adapt each synchronization data structure
specially to pre-v9 sparc, but I don't think this is good enough in
terms of maintainability. Personally, I also don't have time to work on
(3).