MIME-Version: 1.0
In-Reply-To: <20150210181302.GA23886@brightrain.aerifal.cx>
References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com>
	<20150210181302.GA23886@brightrain.aerifal.cx>
Date: Wed, 11 Feb 2015 10:33:32 -0800
Message-ID: <CAMe9rOqX-VpjZ+E-JCusk+e4Kpw1V1tsFq1Kjtai5DR9saKLaA@mail.gmail.com>
Subject: Re: [PATCHv3 00/24] ILP32 support in ARM64
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Rich Felker <dalias@libc.org>
Cc: 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>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3114
Lines: 71

On Tue, Feb 10, 2015 at 10:13 AM, Rich Felker <dalias@libc.org> wrote:
> On Thu, 2 Oct 2014 at 16:52:18 +0100, Catalin Marinas wrote:
>> On Wed, Sep 03, 2014 at 10:18:54PM +0100, Andrew Pinski wrote:
>> > New version with all of the requested changes.  Updated to the
>> > latest sources.
>> >
>> > Notable changes from the previous versions:
>> > VDSO code has been factored out to be easier to understand and
>> > easier to maintain.
>> > Move the config option to the last thing that gets added.
>> > Added some extra COMPAT_* macros for core dumping for easier usage.
>>
>> Apart from a few comments I've made, I would also like to see non-empty
>> commit logs and long line wrapping (both in commit logs and
>> Documentation/). Otherwise, the patches look fine.
>>
>> So what are the next steps? Are the glibc folk ok with the ILP32 Linux
>> ABI? On the kernel side, what I would like to see:
>
> I don't know if this has been discussed on libc-alpha yet or not, but
> I think we need to open a discussion of how it relates to open glibc
> bug #16437, which presently applies only to x32 (ILP32 ABI on x86_64):
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16437

Please leave x32 out of this discussion.  I have resolved this bug
as WONTFIX.

> While most of the other type changes proposed (I'm looking at
> https://lkml.org/lkml/2014/9/3/719) are permissible and simply
> ugly/undesirable, defining struct timespec with tv_nsec having any
> type other than long conflicts with the requirements of C11 and POSIX,
> and WG14 is unlikely to be interested in changing the C language
> because the Linux kernel has the wrong type in timespec.
>
> Note that on aarch64 ILP32, the consequences of not fixing this right
> away will be much worse than on x32, since aarch64 (at least as I
> understand it) supports big endian where it's not just a matter of
> sign-extending the value from userspace and ignoring the padding, but
> rather changing the offset of the tv_nsec member.
>
> Working around the discrepencies in userspace IS possible, but ugly.
> We do it in musl libc for x32 right now -- see:
>
> http://git.musl-libc.org/cgit/musl/tree/arch/x32/syscall_arch.h?id=v1.1.6
> http://git.musl-libc.org/cgit/musl/tree/arch/x32/src/syscall_cp_fixup.c?id=v1.1.6

You are free to do what you feel appropriate.  I have no plans
to change x32 on this in glibc at this moment.

> I imagine the workarounds in glibc might need to be considerably more
> widespread and uglier.
>
> Whatever happens on the kernel side, this needs to be coordinated with
> userspace (glibc, etc.) properly so that the type error (glibc bug
> 16437) is not propagated into a new target that we actually want
> people to use. I'd really like it if other undesirable type changes
> could be cleaned up too, but perhaps that's too much to ask from the
> kernel side.
>
> Rich


-- 
H.J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/