Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756853AbcC2N2V (ORCPT ); Tue, 29 Mar 2016 09:28:21 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:62070 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755423AbcC2N2T (ORCPT ); Tue, 29 Mar 2016 09:28:19 -0400 From: Arnd Bergmann To: "Zhangjian (Bamvor)" Cc: 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, joseph@codesourcery.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 15:27:03 +0200 Message-ID: <3298847.t7vI4YM3gJ@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56FA816D.60101@huawei.com> References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <20160329120147.GA3551@yury-N73SV> <56FA816D.60101@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:oYuMRN9wIOJF7B+g9bXU8B0b3S3LyDxDz1kbQZow/PW8SiCYQ6r Ify7HrPxeQUy6xKawLRa3XfV/erzk+ZkAb/Go5pKlbG7BRgrMrJaK5cLXuXsJfRjR/Eu5xz x7pspbB7nCQVEcsytDJlFMlmuOfSsR/MRcAQOfBkREJvOSWcMwRP+VNvp65GSs8Aio+Xpkr 1kFnddW8JNXdLHxBki9Yw== X-UI-Out-Filterresults: notjunk:1;V01:K0:enFQjZpCmS0=:HP7xKEASnEVBs1Jjb1ftA7 ThVJfGSf4f1dymrsobvYvbW5hryCoPVKZ81cCwc/Cx9dTk3IP3cTvVIm3nSX0L0e8VY167WvK u2QXYGhKbkftwTTN7ar9XxptUzP+E2PWNkAXCRO5ywSH4jOOYPFJ/cVVHltNlirsH3rtElR1T v2dnyax/yq6Q/3uq19d18AXYPjEfBlkTGq00tqrcfukoVIDo4wSmvQnPg5U70JZxk2KEyO+U+ T1iUcNzf92f9neplw2t0SlZR9uZ8DMler/sXadI3RjTVIIf8SFy7/wx4azkGdOAxfX4L4lZz8 HQwcP0F866KC2CdB87QM+ZCfRrdFGAyhuh8W68u9kIlBiPjXHORdS8u5Z9HU9f+sLFil8XWP/ 0svGryfAmkZfUZnsWDuWull+UlVGYoAdNvSvCfqBRGIn6W3z7eN89I67cJ1KOXFuhgHv5WXoe QymJGwXoAYh/v/nNXP66TpPEokUSf8DB9AIkn3i3rX0rnzRBt45D9iw9+d6CP3U3CijdO3s8E ad8waive4GqP52qY/2TaPbsJP1DgxaLEZauNJAJLk0nGOGZxFf6+7d6zeFuinIjeKOpaKeD7r 42w4f5AnxxzU8hckVkiUc5M8VZMbWoaO1TUhpynyMojJbTDefIv4SGVW0qIHeoXd23AZtZTUg s6yqyLu/uJxHAvg4wxVajOZt7Hz1SjneFi1AUMYNHVCfrXt24uQPp8bvSEVtSqGbNbNib7mkH +uRAK5s9nKb5hjTC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1311 Lines: 37 On Tuesday 29 March 2016 21:21:49 Zhangjian wrote: > >>> > >>> Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > >>> aarch64. And truncate and ftruncate is same as truncate64 and > >>> ftruncate64. > >> > >> I don't know what the glibc developers prefer, but I think the > >> result needs to be something like that: either __OFF_T_TYPE is > >> defined as you write above as a 64-bit type, or the user-visible > >> off_t typedef unconditionally uses __OFF64_T_TYPE rather than > >> __OFF_T_TYPE. > >> > > > > I'm not the glibc developer as well, but I think it's OK. > IIUC, it is usually what glibc does. > If we want to define off_t to 64bit in ilp32, the follow syscall may > need to define as non-compat too: > sys_fadvise64 > sys_sendfile > sys_sendfile64 > sys_lseek > sys_splice > sys_sync_file_range2 > sys_truncate > sys_ftruncate I'm not following here. Do you mean in the kernel or in glibc? In the kernel, the list of syscalls is fine, because we already only provide syscalls passing loff_t as I said, and that is 64-bit. In glibc, I think we need to define fewer entry points, not more. Instead of having both lseek and lseek64, only one of them should be provided, and that should always take a 64-bit offset, calling into the kernel with the _llseek syscall entry. Arnd