Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754837AbbKMQLr (ORCPT ); Fri, 13 Nov 2015 11:11:47 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:64349 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754624AbbKMQLp (ORCPT ); Fri, 13 Nov 2015 11:11:45 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Andrew Pinski , "Kapoor, Prasun" , Andreas Schwab , broonie@kernel.org, Nathan Lynch , LKML , Alexander Graf , Alexey Klimov , Yury Norov , Jan Dakinevich , Andrew Pinski , David Daney , Catalin Marinas , bamvor.zhangjian@huawei.com, Philipp Tomsich , Andrey Konovalov , christoph.muellner@theobroma-systems.com Subject: Re: [PATCH v6 13/17] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Fri, 13 Nov 2015 17:10:44 +0100 Message-ID: <6987238.kVeqDX1hGc@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1446507046-24604-1-git-send-email-ynorov@caviumnetworks.com> <3810107.ZiMyX4Iloo@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:SyRv2JkM6D2YSQDfCAuMp8TDoBHjIy7rwtROALlIrvVp9NMdhlu BDgmBEerpvuiMvmv1bn8AHO85LJh0S2jYEEtv9+YqveKgagKV20z8yijDIqZGGbOM5wm8+u X1wtVDRKjG/2QVc/ROHgXGOd7k9qz52bTboU1APVMsgXuDxi0APsoQbKkVQHfzEbBKVjPNB 0MXduFY7rrr4s+K/MCNmw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZyhdwUS3mxY=:ZPNtOXQU9u8XSboK/VgXZk Hw4NFLTvWq2Ibj3wj7reI1LfGSaLjdQeTxCYcuAhut+IdZj617C+kFmKG+nx2U3/qp1MEDvhS 0yAd6TgBmznG/9NtOXhLLhtdBrXl3J2knDJ7qJxyt2w1fhmOwMI2v/JplQU2ke1Vk8y6HUsI8 HliZx7Y4jNzCPr6YBpSuxzU6hwbEJV94DgwEzncuD1L4doGUebNVhhePGm+cQAr03rrA8EQ48 bKIdIDjgQzHzG6IqNOku5BzqARpbuK1OLyEPtAD490sTjk4nirc1mXU3hV0/U3Ohg/wEsP5BX +aBfNaC3ESUrY8Ulk5CgpVX5+GwiGpu/vojlbXr7V7GJIyhSXNa1cZUwqZN+Ux4Kgij12kVR7 iMaAqCR1jRGc2vdyLl61gH65i54XM/1xny2Lan5p3qnW5XrHYNdKlRHNMhDwt9TO30PPXNtXx yI0ELNNeZ01RvWtX+arC+8vP2IzQaPJuDQ36llOx84Pa/sH9tVIYvoU3KDADqm4w31XrLFdAR o/5/APj6zyw9E1lQqryPiz3bcJLVCJGWU/n1Oypro6cfB4i/rqgGecKOLhKRqSCg0WIWXnpDS ZyYY5yK6KCMs+gLRcrTf8tt0W2M4FjdkLz3ockw5cVlRvDtDGU9/n2vEt43v6luT5a0qtFuuL 4lRlcKdKeHHIrcKre5IMWnwmnjbs+GAoiuYWVCf0K22L+YF1CNjCnolklmjrc3UVHyNOIQyrL KiBg2yHUs5TxoidN Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3105 Lines: 74 On Friday 13 November 2015 07:38:49 Andrew Pinski wrote: > On Fri, Nov 13, 2015 at 7:34 AM, Arnd Bergmann wrote: > > On Thursday 12 November 2015 14:47:18 Andreas Schwab wrote: > >> Arnd Bergmann writes: > >> > >> > On Thursday 12 November 2015 10:44:55 Andreas Schwab wrote: > >> >> Arnd Bergmann writes: > >> >> > >> >> > What do you mean with 32-bit off_t? > >> >> > >> >> An ABI with 32-bit off_t, ie. all currently implemented 32-bit ABIs. > >> >> > >> >> > Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit > >> >> > __kernel_loff_t? > >> >> > >> >> Glibc is bridging the user-space ABI to the kernel ABI. > >> > > >> > Ok, but why? > >> > >> That's how the ABI is defined right now. I didn't make that up. > > > > Ok, I guess it will remain a mystery then. > > The biggest question is here is how much compatibility do we want with > other 32bit ABIs? > Do we want off_t to be 32bit or 64bit? I would much prefer off_t to be defined as __kernel_loff_t unconditionally, with no support for _FILE_OFFSET_BITS == 32. This is at least what I had in mind when I wrote the asm-generic/unistd.h header. We should probably find out what happened for the other glibc ports that were implemented for the architectures using this. It's possible that there was a good reason for supporting _FILE_OFFSET_BITS == 32 at the time, but I can't think of one and maybe it is one that is no longer valid. Do you know what x86/x32 does for off_t? Do they also implement both _FILE_OFFSET_BITS == 32 and _FILE_OFFSET_BITS == 64 on top of the 64-bit __kernel_off_t? > > Should we perhaps define __ARCH_WANT_SYSCALL_OFF_T for the unistd.h > > file then, so we provide both the off_t and the loff_t based syscalls? > > I think that is backwards ... > > > > > That would avoid the extra wrapper in glibc when using a 32-bit > > off_t if that is the preferred mode for user space. > > > Other targets like tilegx does not do that and has a pure 32bit mode. > Only score does that. score was unintentional, it was the first port that got done after we introduced the generic headers, and they said at the time that they would change their libc to remove the dependency on the legacy syscalls, but when I tried to remove them later, they had already shipped it with them enabled. After that, I told people to never enable the symbols in an upstream port and only use them for porting their libc internally. We could actually now move all the legacy syscall stuff to arch/score/include/uapi/asm/unistd.h, to prevent anyone else from using it any longer, as glibc works fine without them these days. The __ARCH_WANT_SYSCALL_OFF_T define might be an exception. If the glibc developers want to keep using 32-bit off_t by default on all new architecture, we could include those calls again by default. Arnd -- 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/