From patchwork Wed May 11 10:12:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: zhangjian X-Patchwork-Id: 9067231 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 37D3EBF29F for ; Wed, 11 May 2016 10:15:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 508B7201C0 for ; Wed, 11 May 2016 10:15:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3905F201BB for ; Wed, 11 May 2016 10:15:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1b0RA5-0002fl-PJ; Wed, 11 May 2016 10:14:37 +0000 Received: from [119.145.14.199] (helo=szxga05-in.huawei.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1b0R9z-0002LZ-Rs for linux-arm-kernel@lists.infradead.org; Wed, 11 May 2016 10:14:34 +0000 Received: from 172.24.1.45 (EHLO lggeml427-hub.china.huawei.com) ([172.24.1.45]) by szxrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id AYV36356; Wed, 11 May 2016 18:03:49 +0800 (CST) Received: from [127.0.0.1] (10.111.72.170) by lggeml427-hub.china.huawei.com (10.72.61.79) with Microsoft SMTP Server id 14.3.235.1; Wed, 11 May 2016 18:13:04 +0800 Subject: Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it To: Arnd Bergmann References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> <4119683.coHZhzaE6c@wuerfel> <57329320.1000500@huawei.com> <4876119.A8fbdncu9Z@wuerfel> From: "Zhangjian (Bamvor)" Message-ID: <573305A8.50406@huawei.com> Date: Wed, 11 May 2016 18:12:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <4876119.A8fbdncu9Z@wuerfel> X-Originating-IP: [10.111.72.170] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.573305B9.0074, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 653e91fddc8f3a25f20215ce2f6e565f X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160511_031432_360003_EE1A4047 X-CRM114-Status: GOOD ( 12.89 ) X-Spam-Score: -1.1 (-) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 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, "Zhangjian \(Bamvor\)" , linux-arm-kernel@lists.infradead.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, Andrew Pinski , schwidefsky@de.ibm.com, christoph.muellner@theobroma-systems.com Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, Arnd On 2016/5/11 16:09, Arnd Bergmann wrote: > 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. Do you mean define the following things in kernel: ``` ``` Then glibc could call mmap instead of mmap2. I could not try it now. Because after change off_t to 64bit in glibc, stat is fail. I may need to revert the stat relative patch. > 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. It means that we could reuse the existing code of mmap2 in kernel and glibc. But we need to shift twice when kernel is 64k page. It seems that the first method is more clear. Suggestion? Regards Bamvor > > Arnd > diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h index 1caadc2..3f79640 100644 --- a/arch/arm64/include/uapi/asm/unistd.h +++ b/arch/arm64/include/uapi/asm/unistd.h @@ -14,3 +14,9 @@ * along with this program. If not, see . */ #include + +#ifdef __ILP32__ +#undef __NR_mmap2 +#define __NR_mmap 222 +#endif /* #ifdef __ILP32__ */ +