This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 status?
- From: Allan McRae <allan at archlinux dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 05 Feb 2014 23:48:41 +1000
- Subject: Re: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org> <20140128205657 dot 16DBA74438 at topped-with-meat dot com> <52E9DEB7 dot 4000709 at redhat dot com> <52E9E84F dot 50907 at redhat dot com> <52EA682D dot 90900 at archlinux dot org> <52F03BEC dot 1020202 at archlinux dot org> <52F062C5 dot 6050705 at redhat dot com> <52F06713 dot 1040005 at archlinux dot org> <Pine dot LNX dot 4 dot 64 dot 1402050004130 dot 25166 at digraph dot polyomino dot org dot uk> <20140205001815 dot B59AB7444A at topped-with-meat dot com> <52F1B8E4 dot 8000609 at redhat dot com>
On 05/02/14 14:07, Carlos O'Donell wrote:
> On 02/04/2014 07:18 PM, Roland McGrath wrote:
>>> Well, what we should not do is sit around indefinitely delaying the
>>> release! Revert the changes, run the testsuite on x86_64 and x86, commit
>>> the reversion and start the process for the actual release. It's clear we
>>> do not have consensus to keep the changes in 2.19, which is what matters.
>>
>> Agreed.
>>
>>> We can discuss later in what form such changes might come back for 2.20
>>> (on the whole my view is that the problems are fundamental to the approach
>>> of signal-safe allocation and would best be avoided by the approach of
>>> allocating at dlopen / pthread_create time - where objects opened with the
>>> old symbol version of dlopen, or using a new RTLD_LAZY_TLS flag, keep lazy
>>> TLS but do without signal-safety). I think providing better interfaces
>>> for tools to identify memory allocated by glibc is a good idea, but
>>> largely orthogonal to solving the TLS signal-safety problem.
>>
>> Broadly agreed with some of the details to be argued later.
>
> I will not put forth a sustained objection to the reversion of
> the current AS-Safe TLS patches. I feel like we had consensus
> from the submitters and reviewers and that the fix solved a
> real and immediate problem.
I know reverting is far from ideal for all the people involved in
generating and reviewing these patches. However, I think that is the
approach that is needed to get glibc-2.19 out the door without further
delay.
I have done the reverts on the allan/revert-TLS-changes. I recorded all
the changes the reverts encompassed (in one case the original patch and
a couple of small bug fixes to the generated code were reverted as one).
This should ease reapplying the patches later for 2.20.
I will push them to master tomorrow morning my time (~9 hours).
I will call for a complete freeze about 24 hours after that and perform
the final steps for the release. That means releasing one week behind
schedule on Friday 7th of February.
Allan