mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Rich Felker <dalias@libc.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Pinski <apinski@cavium.com>,
	<linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Pinski <pinskia@gmail.com>, <musl@lists.openwall.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
Date: Wed, 11 Feb 2015 21:41:27 +0000	[thread overview]
Message-ID: <alpine.DEB.2.10.1502112125560.19244@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20150211190252.GB23507@brightrain.aerifal.cx>

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

  parent reply	other threads:[~2015-02-11 21:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20141002155217.GH32147@e104818-lin.cambridge.arm.com>
2015-02-10 18:13 ` Rich Felker
2015-02-11 17:39   ` Catalin Marinas
2015-02-11 19:05     ` Szabolcs Nagy
2015-02-11 19:22       ` [musl] " H.J. Lu
2015-02-11 19:50       ` arnd
2015-02-11 20:12         ` Rich Felker
2015-02-11 20:47           ` Jens Gustedt
2015-02-11 21:02           ` arnd
2015-02-11 21:09             ` arnd
2015-02-11 21:37             ` [musl] " Rich Felker
2015-02-16 17:20               ` Arnd Bergmann
2015-02-16 17:51                 ` [musl] " Rich Felker
2015-02-16 19:38                   ` Arnd Bergmann
2015-02-12  8:12       ` Szabolcs Nagy
2015-02-12 17:07         ` Catalin Marinas
2015-02-11 19:21     ` Rich Felker
2015-02-12 18:17       ` Catalin Marinas
2015-02-12 18:59         ` arnd
2015-02-13 13:33           ` Catalin Marinas
2015-02-13 16:30             ` Rich Felker
2015-02-13 17:33               ` Catalin Marinas
2015-02-13 18:37                 ` Rich Felker
2015-02-16 14:40                   ` Arnd Bergmann
2015-02-16 15:38                     ` Rich Felker
2015-02-16 16:54                       ` Arnd Bergmann
2015-02-11 18:33   ` H.J. Lu
2015-02-11 19:02     ` Rich Felker
2015-02-11 19:16       ` H.J. Lu
2015-02-11 19:25         ` Rich Felker
2015-02-11 19:34           ` H.J. Lu
2015-02-11 19:47             ` Rich Felker
2015-02-11 19:57               ` H.J. Lu
2015-02-11 20:15                 ` Andy Lutomirski
2015-02-12 15:50                   ` Catalin Marinas
2015-02-12 16:13                     ` Rich Felker
2015-02-12 16:30                     ` H.J. Lu
2015-02-12 17:00                       ` Rich Felker
2015-02-11 21:41       ` Joseph Myers [this message]
2015-02-11 19:04     ` Josiah Worcester

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1502112125560.19244@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=apinski@cavium.com \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    --cc=pinskia@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).