From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751713AbcEKILw (ORCPT ); Wed, 11 May 2016 04:11:52 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:65109 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbcEKILt (ORCPT ); Wed, 11 May 2016 04:11:49 -0400 From: Arnd Bergmann To: "Zhangjian (Bamvor)" Cc: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, Andrew Pinski , catalin.marinas@arm.com, heiko.carstens@de.ibm.com, Yury Norov , Hanjun Guo , joseph@codesourcery.com, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, "jijun (D)" , Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, agraf@suse.de, pinskia@gmail.com, klimov.linux@gmail.com, broonie@kernel.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, Andrew Pinski , schwidefsky@de.ibm.com, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Wed, 11 May 2016 10:09:52 +0200 Message-ID: <4876119.A8fbdncu9Z@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <57329320.1000500@huawei.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <4119683.coHZhzaE6c@wuerfel> <57329320.1000500@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:dF6KGjqYLRAfV9TwOrcPGdAIOdAWGIygQc0jhtt9tOWIffckvFZ vyNKuZ3Q7mnC2rXgRTSfW95lwZiTFpdCo8xJFjGS9dB3mJnVeJ+7wbr6DYQsLeMzFczAsab G0VdZ1t2iIzNI8XrO841iy9Sluym4yiKZjyUjTKg7zyenZ20D4c+lrC8M/HYG5rTHjVWLiG 1xyiEXp1NviJXrfyf+Wlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5GSqNMvdrTE=:3XUBBNIJ6AqT7CVQDpUHBS yqUQVje1YYBUAHp+9rgYVCdpG3rwgKK0wwXychm1Tp4jfrLJxbWoHOHhcMbL0irsd9ASkvEAI hMbC8PVxHvRpa4/o1WKknGdWK0sv21MVd1yP1JP2ktYr6HmNSDi9psIqh/S6kXzEFw54HKj3n mMrKGKDyczPbuzU2FX7kTo3+b2fZshtpIz/FI659zG6gW/YLujBxth29UQphbHwCIEE17GF/M ffww7AT9iYGebj377YAw961cvyaxtltm8TWDzu26qgJmHk15jGRC9g4O5i5qBPPu9s5bU9VbG A9ztAaOF+V0TI7xJMiUDSKTfNUmXiAcekEjwQYqA8YUovgIolqf0yb11NA4iWFr7tTs5dYLoj sR30a59QjqFG0dQ21W8gye7ttYYJbjnzWXPRo+tcEuVe1BDimQxB/qQsqAWrzSsTBP1eDQVMT F0RAOGS/IiGWVQXH6ueMCfcnDRJzAviRd0FlvHpbzPKtbotvdBBrF7Ly7C5h23PtIM+kuHTAn fQRufWakECrtt3rgmKQ/dhivOP+tpXHYXGEijwjiFgQAVZxSH7audPwmEgBB0wMLfLV0rz/7m Q4ksyo5OZLPjUN2k/3b3frxhYG6Bc/jR6Q/Dh/HILw2C0vIzcDiRP7k0mMl5dZtJfZ5zlxXgk tdDUh7chOk7GZpVuxx2uFYDGwVYjcQqx5i7TeXIFLdR1o7F+AYV/nVzNwRdaHI3gAkQI57hSC W2+EYQs61qsk5V1m Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 11 May 2016 10:04:16 Zhangjian wrote: > > I don't remember. It's probably not important whether we have the shift > > in there, as long as it's independent of the actual kernel page size and > > user space and kernel agree on the calling conventions. > Well. I am ok with where to shift the pages size because we get the same > result. I was just thinking if we should get rid of the name of mmap2 in our > ILP32 porting. Actually, it is mmap but we name it as mmap2. User may confused > if they do not know the implementations. That is a good point: If the implementation matches the mmap() behavior rather than mmap2(), we should rename the macro by doing #undef __NR_mmap2 #define __NR_mmap 222 in the uapi/asm/unistd.h file for ilp32 mode. Alternatively we can keep the __NR_mmap2 definition but then we need to pass the pgoff (value shifted by 12 bits) argument rather than the size in bytes. Arnd