Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753299AbcDFGvy (ORCPT ); Wed, 6 Apr 2016 02:51:54 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:32969 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187AbcDFGvv convert rfc822-to-8bit (ORCPT ); Wed, 6 Apr 2016 02:51:51 -0400 MIME-Version: 1.0 In-Reply-To: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> References: <1459894127-17698-1-git-send-email-ynorov@caviumnetworks.com> Date: Wed, 6 Apr 2016 08:51:50 +0200 X-Google-Sender-Auth: 7bdwuNstNZxWAwwI2Mur73diBC8 Message-ID: Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 From: Geert Uytterhoeven To: Yury Norov Cc: Arnd Bergmann , Catalin Marinas , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Martin Schwidefsky , Heiko Carstens , Andrew Pinski , Prasun Kapoor , Andreas Schwab , Nathan Lynch , Alexander Graf , Alexey Klimov , Mark Brown , "Joseph S. Myers" , christoph.muellner@theobroma-systems.com, bamvor.zhangjian@huawei.com, "linux-doc@vger.kernel.org" , Linux-Arch , linux-s390 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1725 Lines: 43 Hi Yuri, On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov wrote: > This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem. > It works with updated glibc [1] (though very draft), and tested with LTP. > > It was tested on QEMU and ThunderX machines. No major difference found. > This is RFC because ILP32 is not tested in big-endian mode. > > v3: https://lkml.org/lkml/2014/9/3/704 > v4: https://lkml.org/lkml/2015/4/13/691 > v5: https://lkml.org/lkml/2015/9/29/911 > > v6: > - time_t, __kenel_off_t and other types turned to be 32-bit > for compatibility reasons (after v5 discussion); Reading this sparked my interest, so I went to the links above... What makes you think these "applications that can’t readily be migrated to LP64 because they were written assuming an ILP32 data model, and that will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments" are more likely to be fixed for y2038 later, than for LP64 now? We're already closer to the (future) y2038 than to the (past) introduction of LP64... These unfixable legacy applications have been spreading through x32 to the shiny new arm64 server architecture (does ppc64el also have an ILP32 mode, or is it planned)? Lots of resources are spent on maintaining the status quo, instead of on fixing the real problems. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds