From: Ben Hutchings <ben.hutchings@codethink.co.uk>
To: Arnd Bergmann <arnd@arndb.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Sasha Levin <sashal@kernel.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
fstests <fstests@vger.kernel.org>, Eryu Guan <guaneryu@gmail.com>,
"cip-dev@lists.cip-project.org" <cip-dev@lists.cip-project.org>
Subject: Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits
Date: Thu, 19 Dec 2019 15:48:28 +0000 [thread overview]
Message-ID: <f913d1f409dd4b2a22bcb71a3ddaeb2b87a00671.camel@codethink.co.uk> (raw)
In-Reply-To: <CAK8P3a1HiPLbajjoYQf0N4RBw9eUK6uyC+mOq7LaRmNpgiOgLA@mail.gmail.com>
[+cc cip-dev]
On Thu, 2019-12-19 at 12:29 +0100, Arnd Bergmann wrote:
[...]
> - Users of CIP SLTS kernels with extreme service life that may involve
> not upgrading until after y2038 (this is obviously not recommended if
> you connect to a public network, but I'm sure some people do this anyway).
> For running user space, this requires either a 32-bit kernel with the
> linux-5.1 syscall changes or a 64-bit kernel. If you run a 64-bit linux-4.9
> kernel in a deeply embedded non-networked machine, it still makes
> sense to have working inode timestamps and be able to test that.
[...]
CIP is currently aiming for a 10 year support lifetime, so both of its
currently existing branches (4.4, 4.19) should be long out of support
in 2038. Still, it's possible that some people hope to extend that
later.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
WARNING: multiple messages have this Message-ID (diff)
From: ben.hutchings@codethink.co.uk (Ben Hutchings)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits
Date: Thu, 19 Dec 2019 15:48:28 +0000 [thread overview]
Message-ID: <f913d1f409dd4b2a22bcb71a3ddaeb2b87a00671.camel@codethink.co.uk> (raw)
In-Reply-To: <CAK8P3a1HiPLbajjoYQf0N4RBw9eUK6uyC+mOq7LaRmNpgiOgLA@mail.gmail.com>
[+cc cip-dev]
On Thu, 2019-12-19 at 12:29 +0100, Arnd Bergmann wrote:
[...]
> - Users of CIP SLTS kernels with extreme service life that may involve
> not upgrading until after y2038 (this is obviously not recommended if
> you connect to a public network, but I'm sure some people do this anyway).
> For running user space, this requires either a 32-bit kernel with the
> linux-5.1 syscall changes or a 64-bit kernel. If you run a 64-bit linux-4.9
> kernel in a deeply embedded non-networked machine, it still makes
> sense to have working inode timestamps and be able to test that.
[...]
CIP is currently aiming for a 10 year support lifetime, so both of its
currently existing branches (4.4, 4.19) should be long out of support
in 2038. Still, it's possible that some people hope to extend that
later.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
next prev parent reply other threads:[~2019-12-19 15:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 4:12 [PATCH] generic/402: fix for updated behavior of timestamp limits Deepa Dinamani
2019-07-21 16:47 ` Eryu Guan
2019-10-02 22:06 ` Deepa Dinamani
2019-10-05 18:35 ` Eryu Guan
2019-10-23 22:17 ` Deepa Dinamani
2019-12-12 13:11 ` Amir Goldstein
2019-12-12 21:55 ` Deepa Dinamani
2019-12-18 20:21 ` Deepa Dinamani
2019-12-18 20:46 ` Amir Goldstein
2019-12-19 8:28 ` [Y2038] " Arnd Bergmann
2019-12-19 8:40 ` Greg KH
2019-12-19 11:29 ` Arnd Bergmann
2019-12-19 11:35 ` Greg KH
2019-12-19 15:48 ` Ben Hutchings [this message]
2019-12-19 15:48 ` [cip-dev] " Ben Hutchings
2019-12-19 20:35 ` Arnd Bergmann
2019-12-19 20:35 ` [cip-dev] " Arnd Bergmann
2019-12-19 12:09 ` Amir Goldstein
2019-12-20 22:45 ` Deepa Dinamani
2019-12-23 5:16 ` [PATCH] generic/402: Make timestamp range check conditional Deepa Dinamani
2019-12-23 6:36 ` Amir Goldstein
2019-12-24 1:15 ` Deepa Dinamani
2019-12-28 22:13 ` [PATCH v2] " Deepa Dinamani
2019-12-30 7:34 ` Amir Goldstein
2020-01-03 6:46 ` Deepa Dinamani
2020-01-03 9:58 ` Amir Goldstein
2020-01-08 8:09 ` Eryu Guan
2020-01-08 8:45 ` Amir Goldstein
2020-01-08 9:50 ` Eryu Guan
2020-01-17 9:09 ` Amir Goldstein
2020-01-17 18:23 ` Deepa Dinamani
2020-01-17 19:01 ` Deepa Dinamani
2020-01-19 0:57 ` [PATCH v3 1/1] " Deepa Dinamani
2020-01-19 9:19 ` Amir Goldstein
2020-02-01 9:14 ` Eryu Guan
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=f913d1f409dd4b2a22bcb71a3ddaeb2b87a00671.camel@codethink.co.uk \
--to=ben.hutchings@codethink.co.uk \
--cc=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=cip-dev@lists.cip-project.org \
--cc=deepa.kernel@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=guaneryu@gmail.com \
--cc=sashal@kernel.org \
--cc=y2038@lists.linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.