From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755149AbcEQPjO (ORCPT ); Tue, 17 May 2016 11:39:14 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:59683 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752763AbcEQPjL (ORCPT ); Tue, 17 May 2016 11:39:11 -0400 From: Arnd Bergmann To: Szabolcs Nagy Cc: Yury Norov , catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, nd@arm.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, broonie@kernel.org, linux-doc@vger.kernel.org, heiko.carstens@de.ibm.com, agraf@suse.de, klimov.linux@gmail.com, bamvor.zhangjian@huawei.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, GNU C Library Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Date: Tue, 17 May 2016 17:37:55 +0200 Message-ID: <4173531.IRSphtVpg9@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <573B0A4D.4090704@arm.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <573B0A4D.4090704@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:xyXI8+EY3Q/z3pMUlG2NheOBQnd85QY0O8HrdHr4MISYRnOyeoZ JEphMM08/Iswq80Co3A1y8SXT5cF6JlHmljn6VcwvQ9Z5R+Mzdn8OGbHKW6vfqt2rkWYrru 26jfQFlL2w+xOJKyBUa1ay06GJ4vx2L4G+NJj4Z15f7KjBMeZMajYGq3Bt9D6SSxUCgIErt MNu5Fkr8eL81f/vFjBo9w== X-UI-Out-Filterresults: notjunk:1;V01:K0:wbnt6wyd5Yc=:f7otYIhcPd8WDV8fro310j qLxWWwthghy69vsypDpYwEDA6M5yaamzewjX1g0R8xuBuzFDzpBZsbX/JPpTwZL9fu5drhuBX KmXQ2yd38apbQD7HSO6fr2AZK12BCN++YvpSYTQXZLAptNJC2ebtfSvvZ7a1eEEw7W4tQ/HOK 7Z2ZZ3Yltikh5fqHPuq78+oy+b0ueeNtCFWi6CxWqu2h5ZE+wlgoSJA2o1YDZ2YAsuSVHsu7m 6Nz5IKAJ7jryYqQF2xCl+zoktgAlOq/+s3UOXgLTJxEbuU3QnNteEsU8RlrcQQga9Q2lyoI6V jWKD2nl3N32tZUc3gqDS4ASo24bQlOjZvOraiHqaWXjfEDXxKQ3ifInk4z+x/RlK6ZB0pNAxn 672PNu1HhGibdtrJ6mI5Xw7/2kTDMtScbRPbUGWKom5p9/cMhr6EVtz3nmi1518x3aN5HTxoD P5CJ+qXp/wF0pEFvLPpS1gCwjWvXYJT6FY1QhCxNN2MB0Vl3PvaG0Dl3sIzpnMH6ktMZpshlP v4cjy3DM9TjfM0BLL1X2Z0eLKiHRh1cSA6jSYTi2MQCm4ot1qfXXzGftCxErjxUQounF1Y96T ZkVirPlb8Z5GgkGFQ3haCQZ0HYQugH6ybaRyxeQNS3hQ/YVMTOVBVliYghYs6sk+vjEOfFnms h0HJhWKiw0KERPXBnO/Hk13Nitapev5nGykkM0zAHT1USqvgnIC05sKPd/almbkKTSqwiR/Jd OUM+PckkN1GoT+Jm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 17 May 2016 13:10:53 Szabolcs Nagy wrote: > On 05/04/16 23:08, Yury Norov wrote: > > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem. > > It works with updated glibc [1] (though very draft), and tested with LTP. > > > > It was tested on QEMU and ThunderX machines. No major difference found. > > This is RFC because ILP32 is not tested in big-endian mode. > > > > v3: https://lkml.org/lkml/2014/9/3/704 > > v4: https://lkml.org/lkml/2015/4/13/691 > > v5: https://lkml.org/lkml/2015/9/29/911 > > > > v6: > > - time_t, __kenel_off_t and other types turned to be 32-bit > > for compatibility reasons (after v5 discussion); > > i added libc-alpha to cc, the thread is at > https://lkml.org/lkml/2016/4/5/872 > or http://thread.gmane.org/gmane.linux.kernel.cross-arch/31449 > > the kernel position seems to be that the aarch64 ilp32 syscall abi > will follow regular 32bit abis (apart from signal context and ptrace > related things and syscalls will take 64bit arguments). > > i think the reasoning is that this allows legacy (non-64bit-safe) > software to use this abi on aarch64 without trouble. > > i think this design should be ok for glibc. > > there are some interop issues between processes following different abis > (e.g. shared mutexes, abi specific file formats, lib paths,..) which apply, > but i assume it is no different from existing 32bit vs 64bit issues. > > the 32bit time_t and off_t are ugly and i wonder if 32bit __kernel_off_t > is really necessary. (i don't see where that is changed: it is supposed > to be __kernel_long_t which is 64bit). __kernel_off_t and __kernel_ino_t are always 'long' and 'unsigned long' for historic reasons, but they are not used at all on modern architectures. We could add a few lines with #ifdef to the kernel headers to hide the definition on architectures that don't use them, but that seems pointless given that glibc just defines its own version. For time_t, I'm working on the same thing in the long run: there will be a 64 bit __kernel_time64_t that is always used on all architectures, and a __kernel_time_t that is provided for backwards compatibility with old libc on architectures that started out having it. __kernel_long_t should not be 64 bit on 32-bit architectures, it is the size of the 'long' type in the ABI and defining it as 'long long' on x32 keeps causing problems that we should not add on new architectures. > i think even legacy software should be able to deal with 64bit off_t, > so we could avoid having two sets of filesystem apis or is 64bit-only > off_t more work to do in linux/glibc? All architectures that got merged in the last 10 years only support 64-bit __kernel_loff_t in the kernel but not __kernel_off_t, this includes arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile and unicore32. However, glibc implements 32-bit off_t on top of the 64-bit syscall interfaces. I believe this was done to keep the code looking more like the older 32-bit architectures. I think it has become easier to override now and we just need to update sysdeps/unix/sysv/linux/generic/bits/typesizes.h to set #define __INO64_T_TYPE __UQUAD_TYPE #define __OFF64_T_TYPE __UQUAD_TYPE #define __OFF_T_MATCHES_OFF64_T 1 #define __INO_T_MATCHES_INO64_T 1 for new architectures (obviously not the ones that already use the 32-bit types). I haven't tries this, so there may be other things that are required. Arnd