From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Metcalf Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 Date: Mon, 24 Oct 2016 12:36:27 -0400 Message-ID: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Yury Norov , arnd@arndb.de, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org Cc: kilobyte@angband.pl, manuel.montezelo@gmail.com, zhouchengming1@huawei.com, pinskia@gmail.com, szabolcs.nagy@arm.com, Nathan_Lynch@mentor.com, heiko.carstens@de.ibm.com, agraf@suse.de, Prasun.Kapoor@caviumnetworks.com, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, maxim.kuvyrkov@linaro.org, schwidefsky@de.ibm.com, geert@linux-m68k.org, philipp.tomsich@theobroma-systems.com, linyongting@huawei.com, davem@davemloft.net, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com List-Id: linux-arch.vger.kernel.org On 10/21/2016 4:33 PM, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov > --- > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/arm64/ilp32.txt > > diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt > new file mode 100644 > index 0000000..b96c18f > --- /dev/null > +++ b/Documentation/arm64/ilp32.txt > @@ -0,0 +1,46 @@ > +ILP32 AARCH64 SYSCALL ABI > +========================= > + > +This document describes the ILP32 syscall ABI and where it differs > +from the generic compat linux syscall interface. > + > +AARCH64/ILP32 userspace can potentially access top halves of registers that > +are passed as syscall arguments, so such registers (w0-w7) are deloused. I'm not sure what "potentially access" here means: I think what you want to say is that userspace can pass garbage in the top half, but you should be clearer about what you mean here. Also, you shouldn't use "deloused" here, since it's not a term that's defined elsewhere in the kernel, even though it's been used colloquially on LKML. Provide an actual implementation definition, like "have their top 32 bits zeroed". > +AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32): What does "turned" mean here? And I "next types" isn't standard English; you want to say something like "the following types". Likewise later with "next syscalls". -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db5eur01on0056.outbound.protection.outlook.com ([104.47.2.56]:19456 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757640AbcJXXMe (ORCPT ); Mon, 24 Oct 2016 19:12:34 -0400 Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> From: Chris Metcalf Message-ID: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> Date: Mon, 24 Oct 2016 12:36:27 -0400 MIME-Version: 1.0 In-Reply-To: <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Yury Norov , arnd@arndb.de, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arch@vger.kernel.org Cc: schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, pinskia@gmail.com, broonie@kernel.org, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, bamvor.zhangjian@huawei.com, szabolcs.nagy@arm.com, klimov.linux@gmail.com, Nathan_Lynch@mentor.com, agraf@suse.de, Prasun.Kapoor@caviumnetworks.com, kilobyte@angband.pl, geert@linux-m68k.org, philipp.tomsich@theobroma-systems.com, manuel.montezelo@gmail.com, linyongting@huawei.com, maxim.kuvyrkov@linaro.org, davem@davemloft.net, zhouchengming1@huawei.com Message-ID: <20161024163627.gIBA123AFXHW8-ESovUx5a5mGmu22kCC5KD5KMaVZL0@z> On 10/21/2016 4:33 PM, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov > --- > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/arm64/ilp32.txt > > diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt > new file mode 100644 > index 0000000..b96c18f > --- /dev/null > +++ b/Documentation/arm64/ilp32.txt > @@ -0,0 +1,46 @@ > +ILP32 AARCH64 SYSCALL ABI > +========================= > + > +This document describes the ILP32 syscall ABI and where it differs > +from the generic compat linux syscall interface. > + > +AARCH64/ILP32 userspace can potentially access top halves of registers that > +are passed as syscall arguments, so such registers (w0-w7) are deloused. I'm not sure what "potentially access" here means: I think what you want to say is that userspace can pass garbage in the top half, but you should be clearer about what you mean here. Also, you shouldn't use "deloused" here, since it's not a term that's defined elsewhere in the kernel, even though it's been used colloquially on LKML. Provide an actual implementation definition, like "have their top 32 bits zeroed". > +AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32): What does "turned" mean here? And I "next types" isn't standard English; you want to say something like "the following types". Likewise later with "next syscalls". -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965260AbcJXRJp (ORCPT ); Mon, 24 Oct 2016 13:09:45 -0400 Received: from mail-db5eur01on0051.outbound.protection.outlook.com ([104.47.2.51]:35455 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933644AbcJXRJi (ORCPT ); Mon, 24 Oct 2016 13:09:38 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=cmetcalf@mellanox.com; Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 To: Yury Norov , , , , , , References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> CC: , , , , , , , , , , , , , , , , , , , From: Chris Metcalf Message-ID: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> Date: Mon, 24 Oct 2016 12:36:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [12.216.194.146] X-ClientProxiedBy: MWHPR11CA0030.namprd11.prod.outlook.com (10.175.56.144) To HE1PR0501MB2762.eurprd05.prod.outlook.com (10.172.125.16) X-MS-Office365-Filtering-Correlation-Id: d89e84b6-9940-4601-f72d-08d3fc2bf43c X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;2:XmwzYbIKprzayHLzD5ShZkC7q1H40K6lWAaZ/VurTUCFFn5SbWVmcNdfI618V/8gUnD22GMsSKFE3M6RZBjtoYPW8fOKUwPYX/I780amkTssiAGCGJLajmHLezr8st3VFCE/0NXSlHljVLayOC9grqbgJ6ebPzmLilTQyBV5tYweMUtLsH5HibrDXFADfYYAvjlS/62AfcCgI/YP8vdiDA==;3:EiZbOE2zxSE9amS/jRD+UkEv+ksKbWmoZPu0N2aQCKNkcfI7DnotnFV9ukDA/tLot8UYTMqKxzF4m1IDpjB5SRc+Yxr6idRiNM7SuIlPz/sVcP3Tsul2PJsnkMSNWXON8kPQVq7crPMwUPJQtheRnA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0501MB2762; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;25:VRemSR/HH2K+xeiQ2Ai286BRNYiUxaHW822bILS83wZ4IqBphf3O4Y9cXNievGNXHsrezbLeyN5DM2eVKcKv8jRLI00mzNGM3Q+c/Z2Fzwjb98/v1xFOHKACyT+kMtKYpdWQM/HyBOKOcweqQZUFY6pSb3nnkbcqmBG4fzhQQ+WfrXGsZisjipDvlcy++CSYdnSY2aGgWZyfjw+Mkue7f54EiIwm2pXcIwUjTRPecppKnu/eOnTN4w2GkYcZVK9uB4IYzZSljs3Ugpvi4ZPfAYMsbqebgaD/fa1Lh9VfqhbuzdWEpdYNMxdi1S6T1xqoMlJgC9lJ3Z2lRaUhKEqm0eR2FysIt+vWOA28coa7m8I7JelicEAhSmqyUA4TVFxOt80Vkf7BAKuXUiSThaAJN2yn02JPW70kRg/zUyyO6HGJ9+m9gpSB/UHGce6GR+NU7Q7hFp96vENx8JsLmHQ0QBbvASAwwn+R61Tl7CYzo5sfTDo7GKQjp/E3RVnm9YRslOxig24BTLTlEE4UIpU/SBihwl4k0oX/K3SbdrG7IR9xo2OuD6UZ6sq4p8SppqTiTwFdbFV/SSYau5q/7bwaLKzQSISQQQGVp9BNTmkp3wSykRxFNcmlCc8BrPEj/cuDBovkDdKqPD8br5pqlkwKMudCJp9YlxtwFFJ1roTTpZznr+XHgGvdasRBP2tHX5Mvc3AvEfD+syhCd9ajp5tckHaCCx1qYICiA4XGVz5ZCA0Z5mRvcnTHFlAx1QGNNEZv58B4qEpKEjVpDKl4w/cNPNTatDCSH7VR11BvoY4qa2nXHAaCQnx4GCSfs1Meqd9xcGNVVp89pzLsH9VwdCe5Vg== X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;31:1YOUr+Y8UhjOq0qbCBqa3ovQoRggC2L1QccTuvQ7CIoSYjyKh/L7FT9lbphAdyL0Esx3oodtsmNCK6P+oqKrkSIXLMV8SuCC2LVBSZ+Ch6om3eKbTzRKRHFUM0znm3MFxY1Isq49305f4ar/v1EjGf68yE11BMnCr2IofcDf6Zfme2iO/E+fUICjkoxLf+Wt7B/TQwBvp3hzHRQLxc2BmZJ273WDWq6NpLY4/mBEp3E16YfDz2XKGq6+jjc2teWc;20:owZMwS+Pn30d+xHAvmvbSDgjxmkWfKAO85jMgOOBBTpu/SPn5Q3OetZuRg2iVvc4Luq7LxK6um9EgPqZ4T1yQvVsGget8JUB6EKAC7n31srammHvfZDPRKWw50/8n0gcwQKByd9fYm5enwj/DgGYPvxGxqh9EiCMae4nDEOSaI4gkH2wWwYa6ndVSBNSosAPL9JZcE5y1g1d4m/93ejOFsnY+YH9CYMxx4vSnJq//yvScNsG6swr5CyM0u+ojaouGIy/AbCHmww0v0spaMRDNmxAmrMan4di6//hSYMXBgA2wuoIdHQUYErTDlaoLQ/K0JKoBgw52WuuEg+pdtddxvgbi8WG9qh1URwwRj3PTtptD/kGDGd1NIuD4DAtXYNxmQ41eSoTZu0NJJdRSa+LeAMKMfTJ2WzDzSUSQgrwNPF/GJIvfv0AhrvJQ3agOp7GGoDuuT5jUhp2uXeri42/u2+vh08eaR5E32elJtUYYzBBIcfD12azCmtNd8tB2iX4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(171992500451332); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:HE1PR0501MB2762;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0501MB2762; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;4:h1rzhnAGV4zLC/Z2FEigvSUr/1PmSahG5QgWDxOIjFZ0AdhjEYFqJc6Ci5laDwBRPxbfoazR/UQHb/jZ40JIxLIYYXbRItnmXnyzWb5f6gLR0pStu5Q+etDMPqhmUvOw4dW3FbY/DWU9DDBafEUHY4PBoSWoim/BCty1NDf+IbGOyu8EnM3KDRFNozKxJ0WGwaLABNiC+/AdOxojmkAmsmt/UU12zypip+z4doIVHHBQmKnZxG0mNcnvLXjnluK4kLJVcpzFRuSk7rCeQtJ6R1azqH0jtUPvnPdeuDKxgHECVIzMwcFwmRaAfqyNxSqOeX81A8OgGGMF8RVRyQI0ePY9AdqLtToAyJdOcPd6dbcWWd0/gDreP21if9wq5UlVwcw+PcoTuPxZWoRxNdZw81zr153J+cDqZ76luS+KR6fmYiDAlRUIiPwAvuGphGglRf6GWqeK9Kq3Tr7A/DUOkA== X-Forefront-PRVS: 0105DAA385 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(189002)(199003)(24454002)(377454003)(15975445007)(7846002)(2950100002)(77096005)(4326007)(81166006)(68736007)(305945005)(64126003)(19580395003)(3846002)(92566002)(50986999)(2906002)(54356999)(47776003)(76176999)(19580405001)(65956001)(31696002)(6116002)(65806001)(66066001)(2201001)(7736002)(6666003)(83506001)(50466002)(65826007)(5660300001)(23746002)(86362001)(106356001)(97736004)(101416001)(36756003)(7416002)(4001350100001)(189998001)(81156014)(31686004)(105586002)(5001770100001)(33646002)(586003)(230700001)(8676002)(42186005)(2101003)(18886065003);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0501MB2762;H:[10.15.7.181];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;HE1PR0501MB2762;23:yULK5orm5NZ7/08CQb78K9XGRs4cJsGHhYf?= =?Windows-1252?Q?bpGGVKt1TOrBS8vCR+SpZSsrizc31a3BKBqHJ6CUs+9oCFDXFBGJP++7?= =?Windows-1252?Q?svW6UPJHa0ML+3eoroAVHU017/rVHi+pQpMQUJZAJRuf8Pi1gcq3Tbvc?= =?Windows-1252?Q?mJr0l5C780807ZBsEVNRy6omLn6oZKVzlZj/RONRbPwTfWWqy6pMa6Ww?= =?Windows-1252?Q?JGMAMrV/k8XuYIz8ddZYVADT4sBXabUvWCYyx1R9XLMPPPrVMqRdqkBY?= =?Windows-1252?Q?e0oRYcmAiY86HnY8U5NIYBtiQ8o4SfiddsQTC5dPfFhhpjYRmui+XxNE?= =?Windows-1252?Q?pPZyLNbQ+O6VEzuR4q3+0iZNXzbfU+mPzwx6u8sceUdom4GmiUz5L4PM?= =?Windows-1252?Q?szbt5udUfuav4PrzZSPMIBbqSzOmtFEHmR5jHSjo8nxb+U1cbsfexY1F?= =?Windows-1252?Q?kkeocRJ1HDuYnRJaCrQ8NVUzSmgRR2ViKPGPGKtLvqcODt67R3bH8nLW?= =?Windows-1252?Q?3mD9t73oVnuLbQPuyN9MR7DsxyZ+ZX2AnRy8mfzCzs8hntT0xmjWKgJ0?= =?Windows-1252?Q?snCgOpQ8JPY58zjv/+W6f5Cr/YCM809Ds8a3tgceahPwxT2L7qDO93eh?= =?Windows-1252?Q?/Q/NUd+VJ8lNTq5Yp7x1Rt58JNV5oW7l4RZG4G8W2Lp9rY6fldewU+vp?= =?Windows-1252?Q?8qJfARKFdP8QcmNFxYnHDGrPoDpfa5fm9AaiJMWWGmAg/Pj2S2dJTW7X?= =?Windows-1252?Q?8XW5/0DkRe/vrt1U4qom44OYhK9Ine9p2WgP1lYIhRvgMlhzykITi3Sx?= =?Windows-1252?Q?+1vXtN0LHxmeYiwuO5J0YCmc+svtBjVU+WMmCZEXM1jPgkYXDBbqYUQb?= =?Windows-1252?Q?26LZJFKYlk6BGfUV4Ad0edIAaZKikLnC0LGV/RToLy8kQ0ZHPAjT0c8h?= =?Windows-1252?Q?fOHoEHZrwdnCGEczCC5iErenCLjfkLIRxVm+x5/hp5u3uzCz00ZWmm6Y?= =?Windows-1252?Q?2NVuaX7hNjUtRRRq1BEJ6M+fnzjrHOxqMiqZzzNd9jtCHqjsa65ZzWAN?= =?Windows-1252?Q?17RcNYVOqOfYHE8HwOSo2MSA7e//sBUnJ6PaRrz9FUkx9k+LbAqSlPm6?= =?Windows-1252?Q?LeFjDqCbuvKQPbvuU618JDlGiTkLxY0uh0xCfUUeVCPIcEmsJXJRSqmo?= =?Windows-1252?Q?Av9k+7p2Ohlj5NEJ7YH08zWrwn1NWr8y19mJw1N87AamTLOzvvyGi2Ss?= =?Windows-1252?Q?cdIFumMGldKHiysRuzXU1sleJruKCqcwdZ4oTofiQ/QuhUSvzmx9sZYu?= =?Windows-1252?Q?sGIh3nOn60neWLn3SOtykn33z3cxEEPJgkuRaM9HiTzcOaQqE5QTzBHI?= =?Windows-1252?Q?mldYZ34Q9DpbfQJup/k8q1b0762WTy9/BWTqwvMEGSFbxuXpdKOgNoHQ?= =?Windows-1252?Q?eLOWObuIxINbguN5e+XIwTCpiW9oNCTFgFJbLx2G4jMQHAkUenzz9SR3?= =?Windows-1252?Q?H85oz19jo51MDgSULuZoXwR5a4/joP+Zhmw5rOrf6eab71Z9dwA=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;6:PpMRoUccCAUqsaxC662gpyRDA//t8jDsqGQMS+Xh62fF/ueH+Ui/8XxRV8rnq9XdklZJfzRivIzcrJSfaIB7uPWHADEQv+GPqbJIMnFfTLj6AJXp4LD1enaooPgRORizFlfJzfvX46UQypTSNfyDAeDaZwvkaxTKFsAmb8Z9r30NjnVcTQgVerrdVgKUlmKf9YM6qBYzW3vNm+PY5YH0LcydHw04CSEt8qGf1OjN4OgvRAYOX93lA4YvpgTq96r8MxkuW3oaubepL4IIh2ORJi7uKgCu6YJ0jRsEbO50aeQgzdSiKNJwXTYNM5ydOWfSbjipixQVPRwV4p/U4IbbpQ==;5:inqDhKnKNFYwFZ2NPDvTTITdoQ2c2n05icrDJNcrr4BEsa+0B+23S7EUsv/Eb/5ycSixZBnewNCQCymBV1FAEg+GL6r9mR0e2iO30IYrvRey6Kfe3U0ghbyuw+b9fhBAFhhrCP15f/o5apumg5y0KQ==;24:9VPdQhAhPEs5gTteA2/9Hcvigfdn1cf2dKKysFA9d8q2+s3SGU2Fsni4gJrmnXo4bv4/AF43eUQch2a6K+Du9gKLJdS72getRRgFtTJAXOs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0501MB2762;7:5RU46l0lRpmdfOBRUgMjw4m+HdSGutcxdxzD6joPHhRjbj1w8Yur56T7sg2ii4crOCDl9ygPAKoFscWC6hjv3gTI+8pw/efG5t193F1RgvVjudUYR5gsO3/SWnO+ydCPFe7B9/d8r6OIXIErzx4QU7VAY/50Wego7C/6K+i5nGzuCTpc6R1AnH5XnrEMHEhpwFm6u/0Brydi9ZOcvMX6H8heBUi0W6uPyygkPeoUYn1PEI+AxNr02peRLLxgaNbLdjdQGLCzVmZZwG0HPNjQyjP0358h198aLqbAkOwbXuN5sUBI4ahL+nTfiU3WRRqd/pCX8oMKrycZjXFTqrz6WgOm1LXaZSkASNRdYUPs7K0= X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2016 16:36:42.1104 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0501MB2762 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/21/2016 4:33 PM, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov > --- > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/arm64/ilp32.txt > > diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt > new file mode 100644 > index 0000000..b96c18f > --- /dev/null > +++ b/Documentation/arm64/ilp32.txt > @@ -0,0 +1,46 @@ > +ILP32 AARCH64 SYSCALL ABI > +========================= > + > +This document describes the ILP32 syscall ABI and where it differs > +from the generic compat linux syscall interface. > + > +AARCH64/ILP32 userspace can potentially access top halves of registers that > +are passed as syscall arguments, so such registers (w0-w7) are deloused. I'm not sure what "potentially access" here means: I think what you want to say is that userspace can pass garbage in the top half, but you should be clearer about what you mean here. Also, you shouldn't use "deloused" here, since it's not a term that's defined elsewhere in the kernel, even though it's been used colloquially on LKML. Provide an actual implementation definition, like "have their top 32 bits zeroed". > +AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32): What does "turned" mean here? And I "next types" isn't standard English; you want to say something like "the following types". Likewise later with "next syscalls". -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: cmetcalf@mellanox.com (Chris Metcalf) Date: Mon, 24 Oct 2016 12:36:27 -0400 Subject: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 In-Reply-To: <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> Message-ID: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 10/21/2016 4:33 PM, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov > --- > Documentation/arm64/ilp32.txt | 46 +++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/arm64/ilp32.txt > > diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt > new file mode 100644 > index 0000000..b96c18f > --- /dev/null > +++ b/Documentation/arm64/ilp32.txt > @@ -0,0 +1,46 @@ > +ILP32 AARCH64 SYSCALL ABI > +========================= > + > +This document describes the ILP32 syscall ABI and where it differs > +from the generic compat linux syscall interface. > + > +AARCH64/ILP32 userspace can potentially access top halves of registers that > +are passed as syscall arguments, so such registers (w0-w7) are deloused. I'm not sure what "potentially access" here means: I think what you want to say is that userspace can pass garbage in the top half, but you should be clearer about what you mean here. Also, you shouldn't use "deloused" here, since it's not a term that's defined elsewhere in the kernel, even though it's been used colloquially on LKML. Provide an actual implementation definition, like "have their top 32 bits zeroed". > +AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32): What does "turned" mean here? And I "next types" isn't standard English; you want to say something like "the following types". Likewise later with "next syscalls". -- Chris Metcalf, Mellanox Technologies http://www.mellanox.com