From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25576 invoked by alias); 10 Sep 2013 23:24:45 -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 25559 invoked by uid 89); 10 Sep 2013 23:24:44 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Sep 2013 23:24:44 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VJXIW-00008b-Fq from joseph_myers@mentor.com ; Tue, 10 Sep 2013 16:24:40 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Sep 2013 16:24:40 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Wed, 11 Sep 2013 00:24:38 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VJXIS-0006VS-Vp; Tue, 10 Sep 2013 23:24:37 +0000 Date: Tue, 10 Sep 2013 23:24:00 -0000 From: "Joseph S. Myers" To: "Maciej W. Rozycki" CC: , , Doug Gilmore Subject: Re: [RFC][PATCH v2] MIPS: IEEE 754-2008 NaN encoding support In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00083.txt.bz2 On Tue, 10 Sep 2013, Maciej W. Rozycki wrote: > I infer you'd prefer to have this change committed even though the > required kernel part isn't there yet, right? I have therefore set the > minimum version required artificially to 10.0.0 so that this code is not > accidentally activated on a kernel that doesn't support the 2008-NaN > feature and put a FIXME note next to it. Please let me know if this is > what you had in mind. Yes, using 10.0.0 here seems reasonable. More generally, that would also seem appropriate if a new architecture port were submitted and approved before the kernel port is upstream. Rather than require a strict ordering of components going upstream (binutils, GCC, Linux kernel, glibc; GDB anywhere after binutils), lots of unnecessary delays can be avoided by each component reviewing independently, possibly in parallel, with the understanding that incompatible changes may still be possible if a component you depend on that's not yet upstream has such changes. (Because of circular dependencies, you can't fully avoid that anyway; GCC for various architectures includes information about signal frames produced by the Linux kernel, for example.) At the point when the kernel support goes upstream, the version in glibc can then be changed to reflect the correct upstream kernel version (in the case of new architecture ports, it's possible more __ASSUME_* macros may also be defined, or conditionals removed, based on what was in the kernel version that went upstream). -- Joseph S. Myers joseph@codesourcery.com