From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7000 Path: news.gmane.org!not-for-mail From: Joseph Myers Newsgroups: gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.lib.musl.general,gmane.comp.lib.glibc.alpha Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64 Date: Wed, 11 Feb 2015 21:41:27 +0000 Message-ID: References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com> <20150210181302.GA23886@brightrain.aerifal.cx> <20150211190252.GB23507@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Trace: ger.gmane.org 1423690913 17713 80.91.229.3 (11 Feb 2015 21:41:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 21:41:53 +0000 (UTC) Cc: "H.J. Lu" , Catalin Marinas , Andrew Pinski , , LKML , Andrew Pinski , , GNU C Library To: Rich Felker Original-X-From: linux-kernel-owner@vger.kernel.org Wed Feb 11 22:41:43 2015 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLf2V-0007FK-CT for glk-linux-kernel-3@plane.gmane.org; Wed, 11 Feb 2015 22:41:43 +0100 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754265AbbBKVlh (ORCPT ); Wed, 11 Feb 2015 16:41:37 -0500 Original-Received: from relay1.mentorg.com ([192.94.38.131]:53661 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752282AbbBKVlg (ORCPT ); Wed, 11 Feb 2015 16:41:36 -0500 Original-Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YLf2I-0001J5-Nx from joseph_myers@mentor.com ; Wed, 11 Feb 2015 13:41:31 -0800 Original-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.3.224.2; Wed, 11 Feb 2015 21:41:29 +0000 Original-Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1YLf2F-00037g-U7; Wed, 11 Feb 2015 21:41:28 +0000 X-X-Sender: jsm28@digraph.polyomino.org.uk In-Reply-To: <20150211190252.GB23507@brightrain.aerifal.cx> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:1886799 gmane.linux.ports.arm.kernel:392831 gmane.linux.lib.musl.general:7000 gmane.comp.lib.glibc.alpha:49176 Archived-At: On Wed, 11 Feb 2015, Rich Felker wrote: > > > https://sourceware.org/bugzilla/show_bug.cgi?id=16437 > > > > Please leave x32 out of this discussion. I have resolved this bug > > as WONTFIX. > > From the glibc side, I thought things went by a consensus process > these days, not the old WONTFIX regime of he who shall not be named. > If this is not fixed for x32, then x32 cannot provide a conforming C > environment and thus it's rather a toy target. But I think we should > discuss this on libc-alpha. In the mean time please leave it REOPENED. Indeed. x86 is handled primarily by community review, and even when we have maintainers for architectures or other subsystems, being maintainer serves as a shortcut to presume consensus in the absence of controversy (in the expectation that the community won't object), not to override community discussion if something is more controversial. I've reopened the bug. I believe I made clear in the discussion of 64-bit time interfaces for 32-bit systems that the x32 ABI mistake was not one to be repeated - that since there is obviously no need for nanoseconds values that cannot fit in 32 bits, nanoseconds (and microseconds) values should remain as long in accordance with POSIX. It's absolutely fine for the userspace structures to have an explicit __glibc_reserved padding field in an endian-dependent place to keep the low part of the nanoseconds value in the same place as it would be for a 64-bit type, but if the kernel doesn't ignore that padding for the 64-bit time interfaces then all places that pass these structures from glibc to the kernel need to copy them and zero the padding in the copy. Whether the high 32 bits can be treated as padding for interfaces where long is 64-bit depends on whether the interfaces in question are required to return an error such as EINVAL for out-of-range nanoseconds values. -- Joseph S. Myers joseph@codesourcery.com