From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757229AbbDPLtD (ORCPT ); Thu, 16 Apr 2015 07:49:03 -0400 Received: from mail-bn1on0093.outbound.protection.outlook.com ([157.56.110.93]:42640 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753439AbbDPLsy convert rfc822-to-8bit (ORCPT ); Thu, 16 Apr 2015 07:48:54 -0400 From: "Pinski, Andrew" To: "Dr. Philipp Tomsich" CC: Catalin Marinas , Alexander Graf , Andreas Kraschitzer , "Arnd Bergmann" , Andreas Schwab , "linux-kernel@vger.kernel.org" , Andrew Pinski , Kumar Sankaran , Benedikt Huber , "linux-arm-kernel@lists.infradead.org" , Christoph Muellner Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Thread-Topic: [PATCH v4 00/24] ILP32 for ARM64 Thread-Index: AQHQdiJk6ncK+y7KV0+K350BEd13Bp1LbaUAgAAg8ICAALE0gIAACcWAgAAKfPaAAAghAIAACe6AgAAmWQCAAA7NAIAAfQ2AgAC1mQCAAAw8AIAAV44AgAAGWgCAABdMgIAABdsAgABUuwCAANO8AIAABGoAgAAEFH0= Date: Thu, 16 Apr 2015 11:33:49 +0000 Message-ID: References: <025BB233-8D14-457A-B3B2-C6BD6C3B32EF@theobroma-systems.com> <20150415100153.GA11626@localhost> <2243754.JW5bGY74bP@wuerfel> <20150415153800.GG22741@localhost> <20150415172219.GE26099@e104818-lin.cambridge.arm.com> <552EE560.9070205@suse.de> <20150416110325.GB819@e104818-lin.cambridge.arm.com>,<09A21550-3538-4A8E-AB12-A9A516D3E866@theobroma-systems.com> In-Reply-To: <09A21550-3538-4A8E-AB12-A9A516D3E866@theobroma-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: theobroma-systems.com; dkim=none (message not signed) header.d=none; x-originating-ip: [76.253.1.90] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1243; x-forefront-antispam-report: BMV:1;SFV:NSPM;SFS:(10009020)(6009001)(52044002)(51704005)(164054003)(51914003)(24454002)(377454003)(2656002)(87936001)(82746002)(106116001)(33656002)(110136001)(99286002)(86362001)(46102003)(40100003)(50986999)(76176999)(54356999)(83716003)(62966003)(102836002)(36756003)(19580405001)(92566002)(2900100001)(19580395003)(77156002)(2950100001)(66066001)(104396002);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR0701MB1243;H:CY1PR0701MB1244.namprd07.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:CY1PR0701MB1243;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1243; x-forefront-prvs: 0548586081 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 11:33:49.4016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1243 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich wrote: > > Just for the record (and to avoid anyone wasting their time on what’s available > today): we are migrating this over to option (a) now, even though we would > prefer to see option (b) implemented. > > If we get a consensus on (b) in the next couple of days, we’ll redo things for > option (b). If not, we will have an implementation for option (a) available that > we can hopefully all agree on merging. I don't think either a or b are good in the long run. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch. Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change). Thanks, Andrew > > Best, > Phil. > >> On 16 Apr 2015, at 13:03, Catalin Marinas wrote: >> >> On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >>> We've just started to bootstrap openSUSE for ILP32 with the non-final >>> abi. However, keep in mind that at least for us bootstrapping is a >>> manual process. So changing syscall numbers means we'll need to go >>> through the manual process again. >>> >>> So if you need any help on getting you an environment that allows you to >>> build LTP with whatever syscall abi people come up with, feel free to >>> poke Andreas or me. >> >> Thanks for the offer. It's great to see a full distro being built (even >> though no commitment). >> >> But I'm a bit worried that people started using these patches and we >> haven't agreed on the ABI yet (well, for a while we thought that the x32 >> approach was fine until I've seen objections from others). >> >> Maybe a quick poll on the options, ignoring syscall number details (we >> go for the generic ones) or syscall tables sharing: >> >> a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t >> (POSIX-compliant) >> b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as >> seen by the user) (POSIX-compliant) >> c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t >> (non-POSIX-compliant) >> >> Option (a) is the easiest from the kernel perspective and has the >> highest chance of not breaking legacy AArch32 applications. >> >> Option (b) is more future looking (beyond 2038) but it introduces a >> third ABI in the kernel (incompatible with both compat and native). >> There is also a risk that legacy applications assume a 32-bit time_t. >> >> Option (c) is pretty much what we currently have in these patches. While >> many syscalls are native LP64, it doesn't fully solve pointers in >> structures shared between user and kernel (ioctl being one of the >> affected areas) >> >> I can't tell how bad the impact of non-POSIX compliance is. If this is >> essential, between (a) and (b) I'm more in favour of (a) as the easiest >> for both kernel and user. If we were to start a new ABI from scratch >> without legacy applications, I would have definitely gone for (b) but >> I'm worried about legacy applications still not fully working with this >> option while adding more maintenance burden in the kernel. >> >> -- >> Catalin > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew.Pinski@caviumnetworks.com (Pinski, Andrew) Date: Thu, 16 Apr 2015 11:33:49 +0000 Subject: [PATCH v4 00/24] ILP32 for ARM64 In-Reply-To: <09A21550-3538-4A8E-AB12-A9A516D3E866@theobroma-systems.com> References: <025BB233-8D14-457A-B3B2-C6BD6C3B32EF@theobroma-systems.com> <20150415100153.GA11626@localhost> <2243754.JW5bGY74bP@wuerfel> <20150415153800.GG22741@localhost> <20150415172219.GE26099@e104818-lin.cambridge.arm.com> <552EE560.9070205@suse.de> <20150416110325.GB819@e104818-lin.cambridge.arm.com>, <09A21550-3538-4A8E-AB12-A9A516D3E866@theobroma-systems.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich wrote: > > Just for the record (and to avoid anyone wasting their time on what?s available > today): we are migrating this over to option (a) now, even though we would > prefer to see option (b) implemented. > > If we get a consensus on (b) in the next couple of days, we?ll redo things for > option (b). If not, we will have an implementation for option (a) available that > we can hopefully all agree on merging. I don't think either a or b are good in the long run. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch. Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change). Thanks, Andrew > > Best, > Phil. > >> On 16 Apr 2015, at 13:03, Catalin Marinas wrote: >> >> On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >>> We've just started to bootstrap openSUSE for ILP32 with the non-final >>> abi. However, keep in mind that at least for us bootstrapping is a >>> manual process. So changing syscall numbers means we'll need to go >>> through the manual process again. >>> >>> So if you need any help on getting you an environment that allows you to >>> build LTP with whatever syscall abi people come up with, feel free to >>> poke Andreas or me. >> >> Thanks for the offer. It's great to see a full distro being built (even >> though no commitment). >> >> But I'm a bit worried that people started using these patches and we >> haven't agreed on the ABI yet (well, for a while we thought that the x32 >> approach was fine until I've seen objections from others). >> >> Maybe a quick poll on the options, ignoring syscall number details (we >> go for the generic ones) or syscall tables sharing: >> >> a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t >> (POSIX-compliant) >> b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as >> seen by the user) (POSIX-compliant) >> c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t >> (non-POSIX-compliant) >> >> Option (a) is the easiest from the kernel perspective and has the >> highest chance of not breaking legacy AArch32 applications. >> >> Option (b) is more future looking (beyond 2038) but it introduces a >> third ABI in the kernel (incompatible with both compat and native). >> There is also a risk that legacy applications assume a 32-bit time_t. >> >> Option (c) is pretty much what we currently have in these patches. While >> many syscalls are native LP64, it doesn't fully solve pointers in >> structures shared between user and kernel (ioctl being one of the >> affected areas) >> >> I can't tell how bad the impact of non-POSIX compliance is. If this is >> essential, between (a) and (b) I'm more in favour of (a) as the easiest >> for both kernel and user. If we were to start a new ABI from scratch >> without legacy applications, I would have definitely gone for (b) but >> I'm worried about legacy applications still not fully working with this >> option while adding more maintenance burden in the kernel. >> >> -- >> Catalin >