From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2861 invoked by alias); 28 Jan 2014 22:43:33 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 2740 invoked by uid 89); 28 Jan 2014 22:43:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: topped-with-meat.com Received: from toast.topped-with-meat.com (HELO topped-with-meat.com) (204.197.218.159) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 28 Jan 2014 22:43:30 +0000 Received: by topped-with-meat.com (Postfix, from userid 5281) id C579D74438; Tue, 28 Jan 2014 14:43:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "Joseph S. Myers" Cc: Subject: Re: Unused sys/ucontext.h files In-Reply-To: Joseph S. Myers's message of Wednesday, 22 January 2014 03:26:54 +0000 References: Message-Id: <20140128224328.C579D74438@topped-with-meat.com> Date: Tue, 28 Jan 2014 22:43:00 -0000 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Rt9WckWK c=1 sm=1 tr=0 a=WkljmVdYkabdwxfqvArNOQ==:117 a=14OXPxybAAAA:8 a=GP24H1yblHsA:10 a=Z6MIti7PxpgA:10 a=kj9zAlcOel0A:10 a=hOe2yjtxAAAA:8 a=zIyTnLVDjmQA:10 a=TL3Z3K73DjQ5vRsaZj4A:9 a=CjuIK1q_8ugA:10 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00068.txt.bz2 Yes, the sysdeps/arm file will (probably) be used by the arm-nacl configuration. In general, I am against removing files of this category just because they are not used by any current configuration. That is, files that are machine-specific and for a machine that has some configurations in current use, but are OS-independent. I put them in the same category as the stub files, most of which are not used by any configuration that can be built. Stubs of function implementations provide the outline of the API and a starting point for filling in actual implementations. Similarly, pure machine-specific files provide at least the basics of the machine-specific API that should make sense across all OS configurations of libc for that machine. As with the stub implementations, there is of course always the danger of bit rot. As much as possible, all of libc's APIs are meant to be independent of the underlying operating system. That being the case, people making API changes should endeavor to notice all the different implementations and update them consistently. People will forget, some changes will be untested, etc. But we should still be striving to consider OS independence issues in all of our API choices. Any time there is an API whose only implementations that exist in our sources are for a particular operating system, there is a much increased risk that future changes will introduce or further enshrine assumptions about the underlying operating system that make it more difficult (or impossible) to implement that API elsewhere later on. Thanks, Roland