This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.19 status?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]