From: Adam Borowski <kilobyte@angband.pl>
To: linux-kernel@vger.kernel.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <catalin.marinas@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Andrew Pinski <pinskia@gmail.com>,
Prasun Kapoor <Prasun.Kapoor@caviumnetworks.com>,
Andreas Schwab <schwab@suse.de>,
Nathan Lynch <Nathan_Lynch@mentor.com>,
Alexander Graf <agraf@suse.de>,
Alexey Klimov <klimov.linux@gmail.com>,
Mark Brown <broonie@kernel.org>,
"Joseph S. Myers" <joseph@codesourcery.com>,
christoph.muellner@theobroma-systems.com,
bamvor.zhangjian@huawei.com,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Yury Norov <ynorov@caviumnetworks.com>
Subject: Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64
Date: Thu, 7 Apr 2016 14:18:38 +0200 [thread overview]
Message-ID: <20160407121838.GA22098@angband.pl> (raw)
On Wed, 6 Apr 2016, Geert Uytterhoeven wrote:
> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov <ynorov@caviumnetworks.com> wrote:
>> v6:
>> - time_t, __kenel_off_t and other types turned to be 32-bit
>> for compatibility reasons (after v5 discussion);
Introducing a new arch today with y2038 problems is not a good idea.
Linus said so with appropriately pointy words in 2011.
> 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?
Such broken applications already have plenty of bogus architecture detection
code so you need porting anyway...
> 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.
As an x32 (userland) porter, I can tell you that time_t!=long _did_ cause
non-trivial amounts of work. But that work is already done (at least in
Debian), so you might as well benefit from it.
--
A tit a day keeps the vet away.
next reply other threads:[~2016-04-07 13:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 12:18 Adam Borowski [this message]
2016-04-08 2:49 ` [RFC6 PATCH v6 00/21] ILP32 for ARM64 Andrew Pinski
2016-04-09 2:42 ` Arnd Bergmann
-- strict thread matches above, loose matches on Subject: below --
2016-04-05 22:08 Yury Norov
2016-04-06 6:51 ` Geert Uytterhoeven
2016-04-06 12:29 ` Yury Norov
2016-04-07 12:28 ` Geert Uytterhoeven
2016-05-12 0:20 ` Yury Norov
2016-05-12 9:19 ` Arnd Bergmann
2016-05-12 10:30 ` Yury Norov
2016-05-12 13:35 ` Catalin Marinas
2016-05-12 13:44 ` Yury Norov
2016-05-12 14:07 ` Catalin Marinas
2016-05-12 14:20 ` Catalin Marinas
2016-05-12 14:34 ` Yury Norov
2016-05-12 14:54 ` Catalin Marinas
2016-05-12 15:27 ` Yury Norov
2016-05-12 14:24 ` Yury Norov
2016-05-12 15:28 ` Catalin Marinas
2016-05-13 8:11 ` Zhangjian (Bamvor)
2016-05-13 9:28 ` Catalin Marinas
2016-05-13 10:51 ` Yury Norov
2016-05-13 11:03 ` Catalin Marinas
2016-05-13 13:32 ` Catalin Marinas
2016-05-17 12:10 ` Szabolcs Nagy
2016-05-17 15:37 ` Arnd Bergmann
2016-05-17 15:45 ` Joseph Myers
2016-05-17 16:02 ` Andreas Schwab
2016-05-17 22:45 ` Arnd Bergmann
2016-05-17 15:40 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160407121838.GA22098@angband.pl \
--to=kilobyte@angband.pl \
--cc=Nathan_Lynch@mentor.com \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=agraf@suse.de \
--cc=arnd@arndb.de \
--cc=bamvor.zhangjian@huawei.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christoph.muellner@theobroma-systems.com \
--cc=geert@linux-m68k.org \
--cc=heiko.carstens@de.ibm.com \
--cc=joseph@codesourcery.com \
--cc=klimov.linux@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pinskia@gmail.com \
--cc=schwab@suse.de \
--cc=schwidefsky@de.ibm.com \
--cc=ynorov@caviumnetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).