Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Thu, Dec 19, 2019 at 4:48 PM Ben Hutchings
<ben.hutchings@xxxxxxxxxxxxxxx> wrote:
> 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.

It is also common that end-users keep relying on machines that they
bought for many years after any support contracts end. This may be
fine for a lot of use cases where there is no risk in running an old
operating system, and replacing it is prohibitively expensive, as
software generally does not suddenly stop working after support ends.

With the y2038-safe interfaces and with file system limits, the
difference is that there is a specific point in time when things will
break.

        Arnd



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux