From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27385 invoked by alias); 13 Jul 2012 10:27:19 -0000 Received: (qmail 27366 invoked by uid 22791); 13 Jul 2012 10:27:17 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Jul 2012 10:27:03 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Spd5R-00004c-Mh from joseph_myers@mentor.com ; Fri, 13 Jul 2012 03:27:01 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jul 2012 03:26:06 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 13 Jul 2012 11:26:59 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1Spd5O-0001dK-Nv; Fri, 13 Jul 2012 10:26:58 +0000 Date: Fri, 13 Jul 2012 10:27:00 -0000 From: "Joseph S. Myers" To: Andreas Schwab CC: , , Subject: Re: Remove pre-2.4.21 Linux kernel support In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2012-07/txt/msg00035.txt.bz2 On Fri, 13 Jul 2012, Andreas Schwab wrote: > All 64-bit architectures use the wordsize-64 variants which do not > depend on __ASSUME_FCNTL64, __ASSUME_STAT64_SYSCALL or > __ASSUME_MMAP2_SYSCALL, so these macros can be removed. MIPS n64 does not use sysdeps/unix/sysv/linux/wordsize-64. __ASSUME_STAT64_SYSCALL is defined for sparc64 but only for 2.6.12 and later. None of those macros is defined for S390. Determining whether a macro can be removed requires a careful analysis of all libc and ports architectures, to show for each that either (a) the macro is always defined there, (b) no code testing the macro is used there or (c) although not defined, it could in fact have been safely defined for that architecture for the least supported kernel version - i.e., all the code conditioned on the macro, that is used on the architecture, is safe there for any supported kernel. Furthermore, it's necessary in some cases to check for C function implementations that test the macros being #included for other architectures rather than just used directly through sysdeps search paths. It's necessary to be extremely careful with any generalisations such as the above. So I think the removal of such macros is best done in a separate patch for each macro, that includes an extended rationale going through all the libc and ports architectures and explaining why the change is OK for them all. It's not enough to have done the analysis, it's necessary to explain it so that, for each architecture, it's transparent from the given patch rationale why the change is OK for that architecture. is an example illustrating the analysis required, in the case of __ASSUME_TRUNCATE64_SYSCALL. illustrates it for __ASSUME_NEW_GETRLIMIT_SYSCALL, a case where files for one architecture did get #included for others. -- Joseph S. Myers joseph@codesourcery.com