Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754109AbbKLJX1 (ORCPT ); Thu, 12 Nov 2015 04:23:27 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:57988 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753700AbbKLJXY (ORCPT ); Thu, 12 Nov 2015 04:23:24 -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 10:22 +0100 Message-ID: <4796230.MStNPjWNEu@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> <10433819.KzDuoxzSn7@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:3FwrlQj029atv6z0ahSkm9px1nvHt4cB/d1c8ddVwKhwsPuq3pI d6uv3rS9ulS0d1FWcB77awIhNOFgMDKh2zV+ZkpsaBCF0javEjE14CH6uvUGfLTQJR9K/tr qntN5oV+XwxxDT6Kpl2Ia4CznADPxn+cakYjyhkJXowrYAuDM0fPe0ohYu+M0QcChHSs2FC um03aWa4ZzvIZMHe+aRbA== X-UI-Out-Filterresults: notjunk:1;V01:K0:nlxUCWbR3Gs=:w3rkouobJkP6xaqjQZ7wkT 8Xr9NbWw5sQbyXUKOpg697WBeTHhOb5e34drtS0JGCWR7IDEpaaOLK/+GglOkebgt95XoJ3Nj 5mtmJotsq4WYJDhn31avKrlyMyCNIS3Vz8oZAq5/EDGchdznDVThYAPQCo8/wTIg0DUay6FSH YqwSuq7nj6EBMHg6m1D7Ybf7ziA95rHlcOCqPY405/+VPcRV3b0ruYbvFy4IwaXkI1IW/wVOx hyRJ7up/ExzdEP4zZgQxT9agj8qVP4fFyStO8v7U1LSW2+6qKrZ4OKlpJsflhhJjZ1qftcSk5 fd+wt2WoL4RSTHp+VYKeNxQBgfK/1h3+x+2+/Fj+/VtztmbbCbNU8HBAkwZ06uENakZiWNd2S R+JTb+Y4cpME6aNYVY7Qo5XkZEWbKjOKsgUZHIZ8esFPhxW/cVABdas6gWqKs+psCujdm5kyE vmDDFeUlKNvlEgXdKzxOMDoERyRtBmnxjDYmQEr0Lu7ycBGBQVOSeIckn31dgGU+TvikKTapf CebCL+Nfws//ggOoESEzBjv+h/us1a9tAAnRuR8sxOtCIxmfEQzzi6zxE8FUfP5XuRmVDluwF c5leRDgEukRgXzAKwWTFarfcnGCBH13FBJOkIvhZmHrYFtAH/cflxMl+q7osGx726RffCVpqK eQ0/P00N8KmFoPdu2FGryzKv5n/76IluFaaixTrjyjTBLACU4FiHXRRK2iFdmJ5bzbUd5hC9f jDnHm9FdXwrcnGzU Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1417 Lines: 29 On Thursday 12 November 2015 09:58:43 Andreas Schwab wrote: > Arnd Bergmann writes: > > > I think either way is fine for the two examples. I think it's clear > > that we want __NR_llseek as 62 and __NR_mmap2 as 222. Whether those > > use the compat_sys_llseek/compat_sys_mmap2_wrapper or > > sys_lseek/sys_mmap entry points is not overly important, we can use > > whatever is more convenient to glibc: if we can kill off an > > architecture specific wrapper function in glibc by adding one line > > to the kernel, that seems worthwhile. > > Currently most off_t-like syscalls need a new glibc wrapper since the > existing ones are either for 32bit off_t+off64_t (with split off64_t > syscall arguments) or pure 64bit off_t architectures. Since ilp32 now > (mostly) has 32bit off_t, but 64bit off_t-like syscalls neither of them > fit. What do you mean with 32-bit off_t? Do you mean that glibc emulates a 32-bit off_t on top of the 64-bit __kernel_loff_t? That sounds a bit backwards. I would expect that all new architectures that only have __kernel_loff_t based syscalls but not __kernel_off_t based ones only ever use a 64-bit off_t in libc. 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/