This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware
- From: David Miller <davem at davemloft dot net>
- To: triegel at redhat dot com
- Cc: andreas at gaisler dot com, libc-alpha at sourceware dot org, adhemerval dot zanella at linaro dot org, carlos at redhat dot com, software at gaisler dot com
- Date: Wed, 02 Nov 2016 11:32:38 -0400 (EDT)
- Subject: Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware
- Authentication-results: sourceware.org; auth=none
- References: <1478018801.7146.655.camel@localhost.localdomain> <20161101.125117.2228115672691137607.davem@davemloft.net> <1478081121.7146.673.camel@localhost.localdomain>
From: Torvald Riegel <triegel@redhat.com>
Date: Wed, 02 Nov 2016 11:05:21 +0100
> 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.
I'm starting to clear up my backlog and find time to work on glibc so
it is likely I can do it over the next month or so.
> Or do you intend to write sparc-specific versions of all the concurrent
> data structures that are process-shared?
This would be necessary anyways, if we have two modes. One that does
the pure-userland code path and one that does the kernel helper code
path.
Furthermore, sparc specific versions are needed in any case since we
have the v9 detection even in the v8 libraries. Look at all of the
code that checks for v9 in the dl_hwcap mask when deciding which
atomic operation to use.
> If you want sparc-specific versions, who's going to implement them,
> and when? What do we do in the meantime?
See above.