Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038

[Andy Lutomirski <luto@amacapital.net>]

On Mon, May 5, 2014 at 1:53 PM,  <josh@joshtriplett.org> wrote:
> On Mon, May 05, 2014 at 11:33:45AM -0700, John Stultz wrote:
>> I'd like to discuss some thoughts on how to address the 2038 issues on
>> 32bit architectures. This is important, as vendors are still producing
>> lots of 32bit hardware, which may very well have 24+ year lifespans
>> (think industrial control applications, security systems).  NetBSD and
>> OpenBSD have recently broken their ABI, converted their time_t to long
>> long, to properly address this. So I'd like to discuss thoughts on how
>> Linux can do similar despite our no-breaking-userspace rules, after all,
>> one way or another (almost) all of Linux's 32bit architectures are
>> terminally broken past 2038.
>
> I would be interested in this, not just because of time_t itself, but as
> a general pattern for "how can we transition away from an old and broken
> ABI".  Whether by introducing new system calls, new personalities,
> seccomp filters, or other mechanisms, we should have some ways to start
> such transitions and to smooth them out.  Sure, we never break
> userspace, but that just means we need an appropriate
> CONFIG_OLD_AND_BUSTED option for as long as people still need the old
> ABI.

I encountered this with CONFIG_COMPAT_VDSO, and it would be nice if
there were a clear, mostly-applicable rule for how this should work.

The current situation is that CONFIG_COMPAT_VDSO's name is silly, and
it's 'default n', but the name is stuck so that old configurations
keep being able to run old software.

--Andy