From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99200 invoked by alias); 18 Jan 2018 13:47:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 99180 invoked by uid 89); 18 Jan 2018 13:47:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=encourage, platforms X-HELO: relay1.mentorg.com Date: Thu, 18 Jan 2018 13:47:00 -0000 From: Joseph Myers To: Samuel Thibault CC: Florian Weimer , , Thomas Schwinge , GNU C Library Subject: Re: Upstreaming the glibc Hurd port In-Reply-To: <20180118124537.yampmyfjsbi6wvia@var.youpi.perso.aquilenet.fr> Message-ID: References: <20180118124537.yampmyfjsbi6wvia@var.youpi.perso.aquilenet.fr> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-01/txt/msg00601.txt.bz2 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