From: Daniel Phillips <d.phillips@partner.samsung.com>
To: "Luck, Tony" <tony.luck@intel.com>, Theodore Ts'o <tytso@mit.edu>,
Arnd Bergmann <arnd@arndb.de>
Cc: John Stultz <john.stultz@linaro.org>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038
Date: Tue, 06 May 2014 18:56:22 -0700 [thread overview]
Message-ID: <536992C6.70305@partner.samsung.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F327FAE35@ORSMSX114.amr.corp.intel.com>
On 05/06/2014 02:56 PM, Luck, Tony wrote:
>> and going out with the sign bit set. Perhaps some logging mechanism
>> would be helpful in setting up audit systems to use in sandbox testing
>> and triage on Jan 1, 2038, with a view to clawing back the sign bit.
> We can't wait till Jan 2038 to commit a change - programs want to
> work with dates in the future - allegedly the first Y2038 bugs began
> appearing in 2008 when banks issuing 30 year mortgages were unable
> to print the correct date for final payment.
> -Tony
To clarify, sandbox testing can and should start any time. The "triage"
part attempts to answer the question: what about bad behavior that
somehow slips through the net and manifests only on the day of
reckoning? The idea is to provide admins the ability to monitor their
systems and spot issues at source as opposed to letting things go
silently wrong and potentially cause problems far downstream. Another
way of saying it: what way is there to be sure that the problematic
interfaces are no longer being used, other than monitoring them? It's
clear this is the responsible thing to do, what is less clear is whether
the task could benefit from kernel help. Say, CONFIG_Y2038_PARANOIA.
Regards,
Daniel
next prev parent reply other threads:[~2014-05-07 1:56 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-05 18:33 John Stultz
2014-05-05 19:23 ` Andy Lutomirski
2014-05-05 20:53 ` josh
2014-05-05 23:20 ` Andy Lutomirski
2014-05-06 2:12 ` H. Peter Anvin
2014-05-06 2:21 ` Josh Triplett
2014-05-06 12:57 ` Theodore Ts'o
2014-05-06 17:53 ` John Stultz
2014-05-06 18:20 ` Arnd Bergmann
2014-05-06 20:19 ` Theodore Ts'o
2014-05-06 20:33 ` josh
2014-05-06 20:50 ` Theodore Ts'o
2014-05-06 22:06 ` John Stultz
2014-05-07 2:07 ` Theodore Ts'o
2014-05-07 11:19 ` Jonathan Corbet
2014-05-07 17:28 ` John Stultz
2014-05-09 15:05 ` Theodore Ts'o
2014-05-08 20:37 ` Ben Hutchings
2014-05-09 15:10 ` Theodore Ts'o
2014-05-09 20:39 ` Arnd Bergmann
2014-05-09 22:33 ` Josh Triplett
2014-05-10 0:16 ` H. Peter Anvin
2014-05-10 1:44 ` Rafael J. Wysocki
2014-05-15 12:18 ` Grant Likely
2014-05-15 17:20 ` H. Peter Anvin
2014-05-16 2:50 ` Jason Cooper
2014-05-10 0:19 ` Andy Lutomirski
2014-05-06 21:17 ` Daniel Phillips
2014-05-06 21:56 ` Luck, Tony
2014-05-07 1:56 ` Daniel Phillips [this message]
2014-05-07 14:00 ` Grant Likely
2014-05-09 17:30 ` H. Peter Anvin
2014-05-06 1:25 ` Li Zefan
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=536992C6.70305@partner.samsung.com \
--to=d.phillips@partner.samsung.com \
--cc=arnd@arndb.de \
--cc=john.stultz@linaro.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=tony.luck@intel.com \
--cc=tytso@mit.edu \
/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