Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753381AbbKLN0B (ORCPT ); Thu, 12 Nov 2015 08:26:01 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:58336 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752024AbbKLNZ5 (ORCPT ); Thu, 12 Nov 2015 08:25:57 -0500 From: Arnd Bergmann To: Andreas Schwab Cc: linux-arm-kernel@lists.infradead.org, Yury Norov , pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, Andrew Pinski , broonie@kernel.org, jan.dakinevich@gmail.com, Andrew Pinski , ddaney.cavm@gmail.com, bamvor.zhangjian@huawei.com, philipp.tomsich@theobroma-systems.com, andrey.konovalov@linaro.org, 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: Thu, 12 Nov 2015 14:24:57 +0100 Message-ID: <16446627.b0Lo936ZJj@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> <4796230.MStNPjWNEu@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7bwKslRBcVrDveUNHRJFnk7FGgOzS8Pr24nMCbflAb5uPY7yjrv MjNL5B6L+aEHREEgMEjOXKSo6e1go017L0ckq2q+D7w+D4oq1baVAjZ9Yt4q5ImyqPz1402 yNJrAwRa4zYi9BpgstWAn+d5s17aMzQwrF6ebS29HmtA2bcy149HkHCa0exsHbRt+4Rmbgf l3F+RZZm8Rx4S+Pr44Ncg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3QPgrGsDJIw=:g7FgzjNORc6wxB1mlCSMSw FpNgvaD6yoN3u0BdERpDZXkeMSoCqzRUhC6EPycAg4XWCSWQGaFu5k9+l+QbTl2zJ/mTCYVoo IqsT4suGV3i8pYxXAQVsqPS7ENKjzcqyV5c0u/msmfaTOVbDqH6Y3jTwuPBVVw4QamJn6ehBx HHR774LXZ7gH7DBZxWvU9cxo4P2zu2nKUNnLW1odHBFmEdi6IyYciqTrnhOxgKTcKzXukRYPw PtnNTPkfMstsXI35uPkXmgpahdE7RswrO/nl71LkeZPXkt7k2lh8iHAtK/AuZyC+x16Ha+Stk 92BKoeXuzHTIYVJMjbSXFcZL+CyfmHO7FCCrOfd5jCLwtnwsJJNvQffYkQrmifWl/wB+e7KT0 wMUx4OdjmcVs9bkTHLFoDZxIuNLeeexR3DbvZOOzTw+jZJKBZGIaETebxvQ46DXr7rthJNNIy ZXhX/BmNyOIuKG7uz1a9E8YpaumVhYRgpiY9jXMMAmk3bMh/YP1LbGRFWtV5YR9WAKz9pwkTi tyg+q90qpyAVQr0pZM4rmBaV2f/HGnJsaADnTFl8jADGpVWuaW88yr6epo8fzvnNBCFtHZUca x4Hj3tPjg//gVT6ZSw0rDxtQ1FoyucSzRpdPP3zO/9/zeD+jZ4nAhoA8WhVbdKyr0LkiAr0vZ TB9Xheykpd8yTqzIYU8tlgDODkNhHlgWYjIdRt+N5V4F+p4r3Eyot/PZFt+54AiaXv8h69JMx +T9GfNKmo1JfC31Y Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1112 Lines: 31 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? The kernel headers for all recent architectures (arc, c6x, h8300, hexagon, metag, nios2, openrisc, tile and unicore32) deliberately leave out the __kernel_off_t based system calls to simplify the ABI in a way that we never have to support a 32-bit off_t in user space. Are there programs that require using a 32-bit off_t by default on 32-bit architectures but not on 64-bit architectures? Did the previous version of the ilp32 patch set also emulate this the same way? 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/