This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Upstreaming the glibc Hurd port
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>, <bug-hurd at gnu dot org>, Thomas Schwinge <thomas at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 18 Jan 2018 13:47:42 +0000
- Subject: Re: Upstreaming the glibc Hurd port
- Authentication-results: sourceware.org; auth=none
- References: <bf8a27e5-0df1-7729-c295-dddeee0f4e1c@redhat.com> <20180118124537.yampmyfjsbi6wvia@var.youpi.perso.aquilenet.fr>
Please note (as a reminder from past discussions) that the Hurd libpthread
will need to be included as part of glibc, much like NPTL is a
fully-integrated part of glibc - not a separate package (support for
add-ons has been removed from glibc). (I'd also suggest that it *not* use
a top-level directory called simply "libpthread" or similar without
mention of Hurd, as that would be too confusing to people looking at the
source tree for pthreads for other platforms.)
Also as per previous discussions: Hurd port maintainers can put in changes
to Hurd-specific files at any time (regardless of release freeze state)
until the port is actually working. All the usual coding standards of
course apply, and changes to files that might affect non-Hurd may need
review and not be appropriate at some times, depending on freeze state and
the risks associated with such patches.
In my view, build-many-glibcs.py support for Hurd would be appropriate
even before the Hurd port builds (and certainly before it cleanly passes
the compilation tests). That support will definitely need patch review.
Before Hurd support is fully integrated in glibc, I'd encourage having a
branch *in the glibc repository* that contains such support, so we can
more readily see what the changes yet to be merged are (and possibly
comment on issues that will need addressing when integrating them in
glibc).
--
Joseph S. Myers
joseph@codesourcery.com