This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Thu, 20 Jun 2013 23:46:03 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B65DE4 dot 4010107 at redhat dot com> <20130610231903 dot D9C602C09B at topped-with-meat dot com> <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com> <87ehbwqyxp dot fsf at tassilo dot jf dot intel dot com>
On Thu, 2013-06-20 at 14:01 -0700, Andi Kleen wrote:
> Roland McGrath <roland@hack.frob.com> writes:
> >
> > Correct. This also means not introducing new API or ABI features.
>
> Just to clarify:
>
> The elision patch kit as posted does not change any API or ABI based
> on configure switches. I have no plans to change that.
>
> It however turns on/off elision for existing mutexes and rwlock, so the
> documented behaviour differences in the manual will happen or not
> happen.
I consider constraints on the behavior that is allowed at runtime (e.g.,
the POSIX mutex requirements) to be part of the ABI. The differences
you refer to can violate those requirements.
The *ELISION_NP bits in the mutex type are an addition; they are
unconditionally enabled, which avoids Roland's fragmentation concern but
also, as he points out, comes with the risk of having to maintain them
forever.