This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 status?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Allan McRae <allan at archlinux dot org>, 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 08:55:21 -0500
- 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> <52F24139 dot 7090409 at archlinux dot org>
On 02/05/2014 08:48 AM, Allan McRae wrote:
> 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.
Sounds great. Thank you again for taking upon yourself the responsibilities
of a release manager.
I have only one outstanding patch for 2.19 which is to fix the test failure
for Adhemerval (IBM) regarding tst-setgetname on 2.6.32 or older kernels.
I'll check that in this morning since you've already ACK'd it and I believe
it to be in the form that Joseph was suggesting.
Cheers,
Carlos.