Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753264AbbKKXYy (ORCPT ); Wed, 11 Nov 2015 18:24:54 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:60358 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752993AbbKKXYw (ORCPT ); Wed, 11 Nov 2015 18:24:52 -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 00:23:43 +0100 Message-ID: <10433819.KzDuoxzSn7@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <87k2pojfsy.fsf@igel.home> References: <1446507046-24604-1-git-send-email-ynorov@caviumnetworks.com> <20577001.4Nl3YnQ8k2@wuerfel> <87k2pojfsy.fsf@igel.home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7AWTBwj4Iuo2hwvh2erZQD8qymH8DJNvLCnWEQlSaO03Wz/lDcK CpS9ykegJdVzhpt7GJVPHfjkmayX2AlOT2mFmG6WIJuhOcDEqiYbcMJK41OnKYMCZURpyL2 ctVqLXaN1B8DgtAweK3uobEIf1WXMtj4p4gvPsfeZmmE0IDmPhX5+zH/QyqU8MMtVM477ui mTwe6+1GKDUF2Hw5B/uuA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kqE5vL91PUU=:aPgc2G1gLKQzQU0zIg8IO1 9yBlDv+jm2tJd8wnooBnKVnonD42OoK8wyTWju/E8dQABdwz9pAgPC4Z44JHVpJYOXm+UIuZU LQWZKXfrftU/rxvEyFW8w2wLMdk0ffjMGLZlMBQdVl8LvM0yDcoDHNxuIuF3efF/9hF60Js1O FEsfz1Y+lj8EbBb3QfTBKqtyvrrmMql58sZCUxbJ50vxLE30XPNTxvhJ6Ra3Ux+av4SyHDKFt 6VS+8wyljUFbSV/WMIwerwWNFLDBQrjjWS0MWCsmWQcd5WDVOIRBmf6k9vMzY20NKsP2p8VuB E3PuZFAa3LpPaLavMlDu7MxGvmJb1jyusV5MHF06nDdATn/Hx/HgqR4zlK8Ru7MYIlvjekKnY phVEq3hEuzxcazzIaFauX2LAdAyleWuOZXOJRo0LipB9E9ElQPChnm9yL7n3Pw8tkm5E1h+3P UGb2YoIK6v2HKJZGINv6WW83zfhHAGTGDu1HamWQTUTfwGAp+dC9mcq2oqBPwffxQLQHWxqmk rClZCm4gR5CpgdqfXopMIbouySgvXLeSf9/M1VmKPKTlzZHJ8dG/XG7bj8cOIgXcisjV720GU 7bEIGDK1H3n5iH9nB0w0uPTLiuPql1ASQnsT1SumXAlD2cLlDlFk+av5frJgczga0/EwviFsp uveKFgLyL8+MT5DW+xXbAJCBn/0LjRUXsc6OhawbDYW1jKkgaehZrlxg9ksmqFrUpSaMEiAFD JaoSLKIiCvX++HHO Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1641 Lines: 36 On Thursday 12 November 2015 00:07:41 Andreas Schwab wrote: > Arnd Bergmann writes: > > > On Wednesday 11 November 2015 18:54:00 Andreas Schwab wrote: > >> Yury Norov writes: > >> > >> > +#define sys_clock_gettime compat_sys_clock_gettime > >> > +#define sys_clock_settime compat_sys_clock_settime > >> > >> You also need to redirect sys_clock_nanosleep. > > > > Note that based on my comment, that table would be turned around, and > > only the syscalls get overridden that do not have the normal > > compat mode behavior (mostly the ones that pass a 64-bit register). > > Is it intented that _all_ off_t-like syscalls are implemented by the > 64bit variants? Currently, this isn't fully implemented (lseek is > implemented by sys_llseek and mmap by an mmap2 wrapper). 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. It's a bit confusing, because user space off_t matches the kernel's off_t, loff_t, but not the __kernel_off_t from the uapi headers. 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/