This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
glibc 2.24 -- Cutting the branch and my FSF steward position on __malloc_initialize_hook.
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, GNU C Library <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>
- Cc: Sinny Kumari <skumari at redhat dot com>
- Date: Mon, 1 Aug 2016 11:22:16 -0400
- Subject: glibc 2.24 -- Cutting the branch and my FSF steward position on __malloc_initialize_hook.
- Authentication-results: sourceware.org; auth=none
Adhemerval,
As an FSF steward my position is that we should _not_ revert the
__malloc_initialize_hook changes, and that we should cut the branch today.
My reasons are as follows:
* Late ABI changes should not be happening since it may have consequence
on validation and verification.
* Patches tested by Sinny Kumari (Red Hat) have shown that Emacs 24 can be
fixed to work pre-dump and post-dump. This means that distributions can
pickup these patches for Emacs 24. We expect Emacs 25 to have these changes
(ff3fc21e24edffccce0d42065833e852a6792bd2 remains).
* Red Hat through Fedora is working collaboratively with the Fedora Emacs
maintainers to provide wide-spread testing of the internal allocator in Emacs
through the Fedora 25 release. Other distributions and the community will
benefit from this testing.
* It is the responsibility of glibc to work with the community regarding the
deprecation of interfaces. I believe the community has expressed sufficient
notice for the removal of implementation-namespace symbols. The removal is
not taken lightly and the purpose is to further beneficial performance and
security changes in glibc's malloc, changes which impact _all_ of the GNU
ecosystem, not just Emacs.
Given all of that it seems to me like we are in a very supportive position
for Emacs. We have downstream distro patches ready to make Emacs 24 work.
We have test and support infrastructure to run Emacs in F25 with their own
internal allocator. And Emacs 25 will function correctly. I don't see
that there is a better time to deprecate the symbols, and I don't see
another 6 months buying us any further value.
My only concerns would be if a distribution choose not to adopt a new glibc
version because of the Emacs breakage. This would mean the distribution
misses out on all the fixes in the new glibc version. I expect this to be
mitigated by the Emacs patches and testing being done by the major upstream
distributions.
--
Cheers,
Carlos.