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]

glibc 2.24 -- Cutting the branch and my FSF steward position on __malloc_initialize_hook.


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.


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