From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751617AbcEJLtV (ORCPT ); Tue, 10 May 2016 07:49:21 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:50057 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbcEJLtS (ORCPT ); Tue, 10 May 2016 07:49:18 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: "Zhangjian (Bamvor)" , linux-doc@vger.kernel.org, Andrew Pinski , catalin.marinas@arm.com, heiko.carstens@de.ibm.com, Yury Norov , Hanjun Guo , joseph@codesourcery.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, "jijun (D)" , Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, agraf@suse.de, pinskia@gmail.com, klimov.linux@gmail.com, broonie@kernel.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, Andrew Pinski , schwidefsky@de.ibm.com, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Tue, 10 May 2016 13:48:06 +0200 Message-ID: <7091358.aJt1stteb5@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5731AE2E.2050403@huawei.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <9651510.pg5Vmm8vKS@wuerfel> <5731AE2E.2050403@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:YGtAad5kOGhG9nTIYbXZMBILW7mwUV2IGCjaiyU2TVpytOAWDf7 kFJX1C3NmZsw+PBFV2uoa6S2JLRf5uuqaVAO9xRgA5Nc2DwfZlPzJ6dyHe+p4nt/r8Y5Ar9 P6NRRrOP7rRqJauDLQnaeIdEMlIQPvGwEgE1PnEVilYvrlVpoBWi+zN7b8OYfmS+zLrbjVe 25PztZCAslkKOhKok7YQA== X-UI-Out-Filterresults: notjunk:1;V01:K0:K0a/efgWIvk=:kSg3lapKrkHiZ/cdsHQtB0 y2AHCeuhB6nsNd4M/+zou8oxSvTVg04uXz9iRoBB4CL8uTA82NkvtkgQEheF1OLWBr6eOJrUZ t9bH4CRtO4nK3WzD0K96A5ekK5q6z9TLbY2gHJKyCxHTixj9/NRjbdrniiGix6u8Y6nfZ6U3U Z5I7+VNV72QavSXCR5WethcAJ02hW1rGNMqTywvIrI8eMs1GFSkWFUbOKoNDPE8XspbEHvjB3 7JDR3unuUvqXR3HmK2lQUX5dx7A5Sc84S/MOTCa8fb0EPCuI8BYY1BjMOFtCUaWgTR8H27AnA gSCSsIqllzoQ4rQJDDhti49Mz7yw/5Wy82i7wn7jEpaiwd4X0MNx5hjmfS7jooK0KjBoUP81H VNtOUFIs5Anj9MyPwxMqMaXGC9skQ4LhJfo0GhoKKk6PVylUX3lWWQ80MeYYOAP0uZZYTSEXW NUFyj4HNODl1+MaBfqJntiRQ/c95VIFiHT47P6Hrc6oUZ6jCg1x2Kr4sU1Cg0CvN1rC9ObQYG N11rbMCfTuv8ApEAtWZu5jA/Zu7RvVuSvy2eZZDouQss5JnpXM/795N4ZGTS4qpqRRhadh9Df pHYeQfrR4rpYe9x6R9RyijcjiQuZyOWzUvbc2tufipnlbTYN9yyUx/uC/3qTniyFhD9RzvB2K 8FZ98coXuYx3bRr+R1G6v9xG5uqBDwLI1XBXjzcoYBmWJi3FBSziHOEpBjrOau18RmmwWkAvn 1ErtKA/vNIAkw044 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 10 May 2016 17:47:26 Zhangjian wrote: > On 2016/5/10 16:36, Arnd Bergmann wrote: > > On Tuesday 10 May 2016 15:42:07 Zhangjian wrote: > >> On 2016/5/6 20:37, Yury Norov wrote: > > "include/uapi/asm-generic/posix_types.h" is uapi, we could not check > "ARCH_32BIT_OFF_T" here. Besides, the `__kernel_long_t` is long which > mean it is 32bit in ILP32. should we define something like x32? > ``` > diff --git a/arch/arm64/include/uapi/asm/posix_types.h b/arch/arm64/include/uapi/asm/posix_types.h > index 7985ff6..9baa8d3 100644 > --- a/arch/arm64/include/uapi/asm/posix_types.h > +++ b/arch/arm64/include/uapi/asm/posix_types.h glibc does not use the definition of __kernel_off_t, it has its own copy, so changing the kernel headers would do nothing. > @@ -5,6 +5,9 @@ typedef unsigned short __kernel_old_uid_t; > typedef unsigned short __kernel_old_gid_t; > #define __kernel_old_uid_t __kernel_old_uid_t > > +typedef long long __kernel_long_t; > +typedef unsigned long long __kernel_ulong_t; > + > #include > > #endif /* __ASM_POSIX_TYPES_H */u > ``` This would break all sorts of things, because __kernel_long_t/__kernel_ulong_t are not just used for off_t but also other things. > > On the other hand, glibc define it own off_t in "bits/types.h": > __STD_TYPE __OFF_T_TYPE __off_t; /* Type of file sizes and offsets. */ > __STD_TYPE __OFF64_T_TYPE __off64_t; /* Type of file sizes and offsets (LFS). */ > > in "sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h": > #define __OFF_T_TYPE __SLONGWORD_TYPE > #define __OFF64_T_TYPE __SQUAD_TYPE > > If we define off_t as 64bit in glibc: > #define __OFF_T_TYPE __SQUAD_TYPE > > Should We need to align all the off_t syscall to 64bit syscall in > kernel? > Yes, this is the change that I think we need to make, along with the same change for __INO_T_TYPE and #define __OFF_T_MATCHES_OFF64_T 1 #define __INO_T_MATCHES_INO64_T 1 If I read the rest of the glibc headers right, that should be all we need to ensure that both off_t and off64_t match the __kernel_loff_t based syscalls. Arnd