On Wed, 6 Apr 2016, Geert Uytterhoeven wrote:
> On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
