Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758253AbcC2Vko (ORCPT ); Tue, 29 Mar 2016 17:40:44 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:64691 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754501AbcC2Vkm (ORCPT ); Tue, 29 Mar 2016 17:40:42 -0400 From: Arnd Bergmann To: Joseph Myers Cc: "Zhangjian (Bamvor)" , Yury Norov , linux-arm-kernel@lists.infradead.org, Andreas Schwab , young.liuyang@huawei.com, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, broonie@kernel.org, "jijun (D)" , heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, jan.dakinevich@gmail.com, gaoyongliang@huawei.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, Bamvor Zhang Jian , christoph.muellner@theobroma-systems.com Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Tue, 29 Mar 2016 23:39:48 +0200 Message-ID: <5332965.FKfI1zIepV@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <3398301.sy99ksJOyc@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:6+xruUbhZDV0ckeBFoC0G7wUrnlwovuRcnmx4cK0pAap5G24ACJ j+c7fg67QAXonpDTC4tx9W0uGoot1GySDvEjw9KfYzJH7elLSbEIllDlE347snIw02Ptxvl kr574CH1hV27ImXtlUz6nj2XLJmTODg/I36soJw5xFqKMp5nStV3oXzlTwO1d5tDbY96XT8 S2tQBAiIif6qUJkHPrrIg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rW5+j2w4qdc=:xPrjAJjG2OccOeNKtvBUil 1Q5gYuvX7TEQds67NH9Q1WV6/VT4ZjkZEXj1tONtRoJg6Ybob+MiuBDEIilKQe6r4WAYO2sPm prB2AYJ6ly/jMDXS/+pHKfXEzIVi7ecGwPjAc4ogDus4S7msY7a3OuOiy3fq9oZtrn93YKtpx h3KQmchojtvGDEkl3/QBpRiOzo9SZSPSg+jp6mX5VMRGbr6TvhwoXJr+yE7NLrBy9b4xBCw36 OHCGz5D62w5wVdKxtb4zibtezXmm6j5qDkKX1R/WUC5tuoZ5hIFIUcpgpvA2X5jisiizOqAHV RQWr2zZJHvUjIugzoPScFCwG7VJdoUjNQzasBG+X11Z0BPmAFc6aQ7PalKsn505C/JwiDni3V 8cdTQvpGeXtMI/O1panO0pzNu0uXa11twxA1Js5kiJUrxctuKuuBQpxsGfLJ0Nxvoj4JTKo+p 9HluisFB74GSPrfPFnKtfU5k+Z/ZNJW7eCikq+A0Fy0Tx8SgnkK/zLLALYJ9NuEigLJ04YjYC uokPhSdRUPZlQurAf6e6YLcXFdqpavBoYXMmpP/ClQbVIkqj4kyLmWXvJgg2pGJGDdh5p3F5V uhJLwFYmLyIBTt+lpGmgUuo3WrbLSBWGe8NNDnB9FnT+wJNLVd6hQxr7tWarOTFvDM9Py/Skl JXXB2za1eN04E1aE98vBc015+Aqej/dtUW2Tb/VtyxkyGaAARDeu9ZRzMOw3jwtXThWlZ2WFG bO5WbhQwnrkU6+v8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2297 Lines: 44 On Tuesday 29 March 2016 21:00:56 Joseph Myers wrote: > On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > > > I think so (along with using wordsize-64 sysdeps directories as far as > > > possible, like x32 does). But design questions for a glibc port really > > > belong on libc-alpha to get any sort of community consensus. > > > > I thought the wordsize-64 stuff was for the x86 mode where they > > define __kernel_long_t as 64-bit. We don't really want to do that in > > the kernel for new 32-bit architectures, that would make the kernel > > ABI different from all the existing architectures. > > In general the wordsize-64 directories cover various relations of the form > "function X is an alias for function Y", which derive from "type X is > ABI-compatible with type Y". (Unfortunately, the precise set isn't > well-defined, resulting in problems for cases that want a subset of those > relations - e.g. MIPS n64 where struct stat and struct stat64 are > different, and so sysdeps/unix/sysv/linux/wordsize-64 isn't used.) For all new 32-bit architectures like this, the kernel should at least behave in a consistent way, but it's somewhere inbetween wordsize-32 and wordsize-64 for 32-bit architectures, because off_t and ino_t are mapped to the 64-bit __kernel_loff_t and __kernel_ino_t, while time_t, clock_t and size_t are mapped to 32 bit types. > The person doing the port will need to do a detailed review of the exact > effects of the wordsize-64 directories in current glibc, and which of > those effects are appropriate for this port, to determine what is > appropriate, and to include that analysis with the port submission. I think the analysis will have to be about two separate things: * Whether new 32-bit architectures in general should use wordsize-32 or wordsize-64 or something else, based on what you write above. I would still guess that we are better off adapting wordsize-32 to the current kernel ABI for 32-bit architectures while leaving wordsize-64 to real 64-bit architectures and x86/x32. * How we deal with the special case of this architecture having nonstandard calling conventions for a couple of syscalls that take 64-bit arguments in a single register rather than two registers as every other 32-bit architecture does. Arnd