Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752391AbbDPPW3 (ORCPT ); Thu, 16 Apr 2015 11:22:29 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:63425 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752190AbbDPPWQ convert rfc822-to-8bit (ORCPT ); Thu, 16 Apr 2015 11:22:16 -0400 From: Arnd Bergmann To: Catalin Marinas Cc: "Pinski, Andrew" , "Dr. Philipp Tomsich" , Andreas Kraschitzer , "linux-kernel@vger.kernel.org" , Alexander Graf , Andrew Pinski , Andreas Schwab , Kumar Sankaran , Benedikt Huber , "linux-arm-kernel@lists.infradead.org" , Christoph Muellner Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Date: Thu, 16 Apr 2015 17:21:30 +0200 Message-ID: <2242025.Z9qPVP4zls@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150416133134.GC819@e104818-lin.cambridge.arm.com> References: <025BB233-8D14-457A-B3B2-C6BD6C3B32EF@theobroma-systems.com> <20150416133134.GC819@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:foDeOqQPwYNob8b4fNqMPlRBHlDphq+ospTmqa41Y1F5q4LiN+W G2N3LzJEGOlR1+zIoIfFppreTTKiTbtMMK7Hl7v12nRcOL7e/G68V1oT3N2l7TBxdUnVGvy YNV/AzL2FpV0+GWUWKLjJPH0vfQAyy8BJC7QjUie621zRBTSHoOVJRC2d6aJOR2chX5+KP5 mxXFoVBAWBFMC0de6R9eg== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2389 Lines: 51 On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote: > On Thu, Apr 16, 2015 at 11:33:49AM +0000, Pinski, Andrew wrote: > > 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. > > b would have been my preferred option if it wasn't for the legacy apps > support. We could also do it without much hassle in the kernel *if* we > disabled AArch32 compat support (basically use the compat layer for > ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 > should be a build time option. Right, that would be a clean way to support it, just one with a significant downside of not being able to use both ILP32 ABIs concurrently on the same system. > > 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. > > It may be the only one but we could end up with a non-compliant > timespec. Unless we keep the tv_nsec as 32-bit long and add some > padding, we could work around it by getting the C library to sign-extend > such padding or we do it in a new "compat" layer in the kernel (but both > cases imply copying the structure). > > However, timerspec is included in other structures, so we'd have to > intercept those as well. Philipp provided a list here: > > http://article.gmane.org/gmane.linux.kernel/1931497 We're basically in the same boat as x32 then, and should do the same thing on both most importantly, whatever that ends up. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/