From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030544AbcJ0OPU (ORCPT ); Thu, 27 Oct 2016 10:15:20 -0400 Received: from mail-bl2nam02on0065.outbound.protection.outlook.com ([104.47.38.65]:19593 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S936486AbcJ0OPK (ORCPT ); Thu, 27 Oct 2016 10:15:10 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Thu, 27 Oct 2016 12:40:07 +0300 From: Yury Norov To: Chris Metcalf CC: , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 Message-ID: <20161027094007.GB3666@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [176.59.35.249] X-ClientProxiedBy: AM5PR0101CA0022.eurprd01.prod.exchangelabs.com (10.169.240.32) To SN1PR07MB2255.namprd07.prod.outlook.com (10.164.47.149) X-MS-Office365-Filtering-Correlation-Id: fe189621-2b9a-43e9-0bf4-08d3fe4d433f X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;2:zagnr3k1Ls/PlZZXgmZC8wo1MJ1Uh6ivqB57i1kg91La1zse16adsiPM2fATF5n4GRakced21dNzn1pjj0HdPN3RDpi/bOPEssTJsXvRBAN6fQK89S9R4kxMswkIgc7PYCQisZYOBgy45BT5JSfzy2cpAYO+8ufP2Yio2XA+sc63jlJD223rByie8EcS9/tmvG3fczmM4dzCv351FKtDjQ==;3:K4twjrh9ZTG6tjjPKVC2e7XyPRVOv5CKv4rTGshUFcwvIEjKpudgVN2/NGl53fsPcqNJV1aCnGefE5tUmCLcBENujZQEJ7A/i/YXqA0e6g5bwOy6BYwqvOIGdJhJRvBcY1KR8dCf2FEGRICGUe2UPg==;25:9UCGiZqVTIOkhunnTQJdSVhQkKzUEpAaADDspxledNh92pOLB32Wc9xjQW7OiMletEvXxcLaRFOtsvG7U1lyyMAxrBPXN/m5KORQP/7CJYt6zkATK/1ilEXXT3v1/rZ53dZIZ33X2Pperev8NGwXbT/EaLqM3nOCijikVuJwRYpo1C8jEI8B96eQz+ZG6MITyJuNp43PAYxY1GvGaGut01JzPdstNRUNzsDE0CI7JdHaLYl/FYfSTo8L5hRJ21Hm4Nw09TiV56JmJfLd5Lc7sCFeMK38AFrErkNkq2gvg9yT4ZlKT7Zo/CPAXHaVwW5LpoRtnYm9z8qTpHVGHrXpw6rBkkWPOZ8v2IKNYiWuuPKzSnXHGxZ5cwdvzPhu1tLEOGnkBnTX78mmrh3BY90ekILhrsPmzCvcZZGdXxfe9YQ= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2255; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;31:dgfokauDOn1yWUpjIj7/3EBfOf2PEdA2bP/IYZ6nsajFjfM4ur1sGuSjBmfwNlD9Tx9NWJL0c46VW6l+KUwSTh8+3jIr51OSDYWRY84Svws1+vQqjQFMwuhGfKb5UzFSr4W7Qyv9Hu8Lz7KVIkGvpEuOr9zOVwoMiQrorZkQrFPhcd1sX+Bw5c9Xclv6RF4fI8YCwSlu6LxHWv6ekTWLnizTOYkZBwywyZZ/1A3rIXsgCkGnkm5DLoAFPLR9d9hSYVbQuC5QbKPR19tRA4T13g==;20:rPtdKKf+zdQpPpCKm0RTh2TQPY65nOnDpBao5S+xjrCnBZyeM05epNCI4cGdecQxQb8YlYQoNogcTtepSJBb3kCpIrqLutDMFffz3CWwpnSY2vjkbgC6mRoJf3UV3hHytYEtRpOOkFRr8W/Lu85MeCpZNtr96uZCWq4c4QxpN1S/07k24keR0J2/V9+s1fUej98g/L4podT0cvcn6pg/taGVZjPHe5WwLalzuhSK2LJuHJV6TRX5jZMwu7RR4hFVBzDKEaL3ragRN1eAAvb66q1UNGPg+JGUs+dBMa/R+oioBYnrVRlEhiK/pN36npyOF5SVLyKBTfCPlAkk+s279c7xhohj/+u/Lgav8fzKxf3L0R2/76i2WS7XuCaS8uFkPTafzvTxekK8VPSi6NuZKQuElAA0nutJz/y6tZNNFHQ8QqSM/35RMiA2w65TfbhkEcmlIlSd5luh4TaxUgas/phGrpoqpVKiiBc52KCa1oF+EYYeE/SU56F2c9bOw962CURfeXXGv8105zCBfJs2tfb8qa3rkVEl6rkKVEmbq1Ren6GsOQMamXSPRHlYaHoJH4ccwJSjjYglI8IoKSRdHiBzIhCHDVxPI8ohy0O0hUw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:SN1PR07MB2255;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2255; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;4:GLwOATUGY2xqP2aw46zMopu9KOyU8ZNCks2EQutoVoAd3DRb9CABIpLirmPQzTvhw8S6u748AEm10UUDY1kuU929ia+nhEXsThrShnx7Rm32KpzT7lb0Bv/hIui4CpNN2ZfJJO2+X51RI8olC9suuECMNqBIX0Qm+gGik1ACzzMXvlfaXcG3y5ap/7ynXpokPjiqgqQHcgfN559d9hPsktraWjxh9VPFbP4jOWNl3LZ+n3aFIRQZmoWIEOqib9rnjkmqNj/KEltHq2PrbSkL9mgFW6cRdNcyvdY9SZHpupCLF9G0ZGgp7I0OLZwgGUuBSpy1E8LKomlBt8yHuJ6rMhN2FKLOzv/orm0g8E32cSyVkW/U571noOOrj6WMQUUDGvcICEBxZAYEpOEyLVSuqw== X-Forefront-PRVS: 0108A997B2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(2906002)(7736002)(305945005)(2950100002)(6916009)(6666003)(42186005)(50986999)(97756001)(7846002)(6116002)(50466002)(83506001)(110136003)(77096005)(92566002)(1076002)(33716001)(97736004)(81166006)(4001350100001)(81156014)(9686002)(8676002)(7416002)(76506005)(4326007)(345774005)(19580395003)(189998001)(19580405001)(66066001)(23726003)(46406003)(54356999)(101416001)(76176999)(68736007)(33656002)(47776003)(105586002)(106356001)(5660300001)(586003)(3846002)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2255;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;SN1PR07MB2255;23:49k7gNU2E61/m0JM5T9JFMWEDKUtN3PqNBZtK4iL2?= =?us-ascii?Q?taQeaG1nbcC1qNxKxLMJpFnh4dfWL7QCXmwrJWiFqnh09WcheFKoAKDw7Vy6?= =?us-ascii?Q?y1/UnRFEEt1MUO1sHv+OQtfcJN8+jDtzBZvJxciJ/6hjkhfS7zjoAcCdO1a3?= =?us-ascii?Q?J8tj4zJNkzyOAscrkMWTiGKq71Z+YYq7HTtC3uo7SebSQW9d5oDG+lEaOngY?= =?us-ascii?Q?/Gi+aG15AVuvjc0TkP3m4qCKheVWY9c+GoMw0vMqjdv5ppeOfLD0iKjR11bq?= =?us-ascii?Q?sV/WTQX7POLR47shFOPzyMqnBcHXi/r3fvd9QkyLh13eDm3RFZFw8vsu4B5v?= =?us-ascii?Q?3gJWFr3dhzciaEmSBBgVpzSuc4BSqEfT4SJXSI/mKcKQToCnaHI83Ygv0rtr?= =?us-ascii?Q?v3F5vx4ght7/cDgfeEjAA7moM9DNBmfsIiOwVpK5ak56wWJrQUle51r4Wp8O?= =?us-ascii?Q?EM2yYVbdxEsLgPqbhS2893XZw3kob+1n62+8cxZfr9Nt77MFgekmW8Pkj9CV?= =?us-ascii?Q?y4RBgOldHj9/cccEh8eJLQ8geQWT0YrtpQUTtzR00cJwhDg5V8IHhaO1uTpw?= =?us-ascii?Q?LWJ8L0tGmb2/cY5ECLIuT/4CEvdkI/g0LkS7CD8kP2lONUJ0Q9JuH3dhBP08?= =?us-ascii?Q?Vcx6oip5cYbPsI2zCwq8G2gaPwJJnxFHccIDRvE73ei9zyLY63OXsg3B1LXC?= =?us-ascii?Q?jL8cnlkFCiU8EMHyg/kENI4jL0981CTsN245CvKLvDeFKTLsNmZlL/0q/GIp?= =?us-ascii?Q?SaIIWyk0QG0zgobD+0H6yjKGjw8xKUNnYTnpI5o7INbwnWw0Xv+NLuxrX+DW?= =?us-ascii?Q?pIJtsJXX1SOwWr0q5NMlsWohaK/t2k0LVmPIl/ZBhUZJ2HXyNYwKk2pYbyhp?= =?us-ascii?Q?/gGjFh7OR59h1YqEieQbJe0EToOetwWYxDMe2JKq9mbl/9NsNcXd/puEcgE7?= =?us-ascii?Q?Y2btTq52At1IV/Wr4m6eR19f94SyByr6L8dmVfincTe2BfiPDkhgp+OR6uHm?= =?us-ascii?Q?p03kQ8LYH6t1lNjQbt8RIK9nWEFrVlLWlnwonCF24hzMa0jAgxOA5tF+lixA?= =?us-ascii?Q?ovwu9kRPqhfQtbNpbVr0n7WrG85QHhThJQw/EAklqClLrRnGP5GbvOm3WxKO?= =?us-ascii?Q?0Xo2AdJSKc+eMQ8l5VRL2XT0rBFBRio+lnD636nT14sIljPcJEsdr41vzpri?= =?us-ascii?Q?jCtXir9UV2NgRv34OXy4mHwPuYCcaeD8+tVzwxm/pn9R8On/ydQuAG2NhCVa?= =?us-ascii?Q?KuEI17V/PGrIo81mmkIpZI6wBZZSPcjpWzsvFL+FxOk3G8aePg3hmZBHGDFM?= =?us-ascii?Q?Ij721ThJNvThbKOCSJkhiEkjut/xU0sChDEFcSXlQIo?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2255;6:SmDSa+j95y4xDbUGC/AUhwlqoXnoxuporaBQYUgnZU7FCyaEwwsojvkuPjmMhH47RItCGCH01ux+uO8nGNMptWlxOgVmv+aBDqH70fMFlrR9polg6CJa460cOH3l0zEGXBwCUSPxQ6ZFgt1AAHGpur+LSkRGLjFSsD42OfmXDo9sT3gxWX7rhcGICViSm41sTl2/2LKpUC/HO7U8GOoskRXX5v1jeEFn6OhhW5lC0QX7ZJxohsAOZqZSb84ea64TLNHcKuHx4RCovQIE7YbgmODx68NpduH4IIDy6rgQinCuwlzuVjX0iGrVovtpmwFT;5:paeikdQWYZzFo+VKVzu3k0ppSHSz2bsNW76RKjeSCDzB+KYdphmTQzQ1vH7SHSq5UOcrmGREquonikmHEBanVCa9dr+0G+Ruv2sEKresZ9l738dW7qsj69liFSreSfb9YVc7oLV3/PCu6HbVMsNpP6IE91M8r+h1yp/LW7S7aJM=;24:NE4ap0fpdCTFCzO+OubrhRvEhwUq+lQ/6rfVJaV8c1pvM06jl1nXGqb3DNQs8C8mA1U9Ihqm+6KNc+ax1CoBrylvP5wLB6bjBhm3tG7nyRg=;7:qC8Q1ji4dTpbIqea+7CrTwxHUg8n1RXQg9rGbLo+lkmYT64tOaXBWbjliif85WCRFBls0FAdP9grELA0lR+cMaCPGYyHT83xNlRH1IpMnDIT0EWxOCO8W33bOXMhMYIs69YmQTAoi9kunSAe9IzCbCwETWz2QlgBDEAHs0GxNp2RpRtBV+HqURuqtrrC62wUn0LWErl80l7gDsLOH3GLnUcT2AmQNsIygE4HFYrX0ly8B5EOF33Z1jf2rw9nGCrAHxsSmqeonJ5dhgyVvr/8AV6n4Sfj9Vviw3AFlA8mftih0DKtDlzJxwaBlOnJzber69bXxDaFp5pFzSQm1eF2CHiNc6IYbXG+8e+PP2NWK/0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2016 09:40:17.8480 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2255 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chris, Thank you for comments On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote: > 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. Yes. Will change. > 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". Agree. In fact 'delouse' is used in the name of corresponding macro in include/linux/compat.h: 29 #ifndef __SC_DELOUSE 30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v)) 31 #endif But it's not for documentation. > > >+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". Thanks, will change. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yury Norov Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 Date: Thu, 27 Oct 2016 12:40:07 +0300 Message-ID: <20161027094007.GB3666@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.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: Chris Metcalf Cc: linux-doc@vger.kernel.org, szabolcs.nagy@arm.com, catalin.marinas@arm.com, heiko.carstens@de.ibm.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, linux-arch@vger.kernel.org, zhouchengming1@huawei.com, Prasun.Kapoor@caviumnetworks.com, agraf@suse.de, geert@linux-m68k.org, kilobyte@angband.pl, manuel.montezelo@gmail.com, arnd@arndb.de, pinskia@gmail.com, linyongting@huawei.com, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, linux-arm-kernel@lists.infradead.org, maxim.kuvyrkov@linaro.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, davem@davemloft.net, christoph.muellner@theobroma-systems.com List-Id: linux-arch.vger.kernel.org Hi Chris, Thank you for comments On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote: > 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. Yes. Will change. > 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". Agree. In fact 'delouse' is used in the name of corresponding macro in include/linux/compat.h: 29 #ifndef __SC_DELOUSE 30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v)) 31 #endif But it's not for documentation. > > >+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". Thanks, will change. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bl2nam02on0065.outbound.protection.outlook.com ([104.47.38.65]:19593 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S936486AbcJ0OPK (ORCPT ); Thu, 27 Oct 2016 10:15:10 -0400 Date: Thu, 27 Oct 2016 12:40:07 +0300 From: Yury Norov Subject: Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 Message-ID: <20161027094007.GB3666@yury-N73SV> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <1477081997-4770-3-git-send-email-ynorov@caviumnetworks.com> <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Chris Metcalf Cc: 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, 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: <20161027094007.9jut7jHxgTZybnn2f8lBqmco00fP2Ow4IH4uLuNiAtc@z> Hi Chris, Thank you for comments On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote: > 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. Yes. Will change. > 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". Agree. In fact 'delouse' is used in the name of corresponding macro in include/linux/compat.h: 29 #ifndef __SC_DELOUSE 30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v)) 31 #endif But it's not for documentation. > > >+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". Thanks, will change. Yury From mboxrd@z Thu Jan 1 00:00:00 1970 From: ynorov@caviumnetworks.com (Yury Norov) Date: Thu, 27 Oct 2016 12:40:07 +0300 Subject: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 In-Reply-To: <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> <352ff60e-3975-8421-3274-3a904c0ac642@mellanox.com> Message-ID: <20161027094007.GB3666@yury-N73SV> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Chris, Thank you for comments On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote: > 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. Yes. Will change. > 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". Agree. In fact 'delouse' is used in the name of corresponding macro in include/linux/compat.h: 29 #ifndef __SC_DELOUSE 30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v)) 31 #endif But it's not for documentation. > > >+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". Thanks, will change. Yury