3 ms·
Well, that was certainly interesting! I was curious what the current state of things is, so I had a look around LWN. It looks like, as of 2020, the kernel's p
by CaliforniaKarl 4y ago
Well, that was certainly interesting!
I was curious what the current state of things is, so I had a look around LWN. It looks like, as of 2020, the kernel's post-2038 support is essentially done[0]. With kernel 5.15, XFS' support for post-2038 dates is no longer experimental[2]. That seems to be last mention of post-2038 support settling out in the kernel. The musl libc also has switched over, in a breaking change[1].
glibc seems to have taken a much more nuanced—and much more complicated—approach: You specify, as a `#define` (or compiler command-line `-D`), that you want a 64-bit time, and all existing types (like time_t) are updated accordingly (by redefining them as aliases to ex. __time64_t)[3].
This reminds me a lot of how glibc handled the switch to 64-bit file sizes on 32-bit systems: You either defined `_LARGEFILE64_SOURCE` to access to 64-bit types & calls (like off64_t), or you defined `_FILE_OFFSET_BITS=64` to redefine the existing types & calls to their 64-bit equivalents [4].
I wonder what the current status of post-2038 work is for Debian?
[0] https://lwn.net/Articles/838807/ https://lwn.net/Articles/838807/, "After years of work, the kernel itself is now completely converted to using 64-bit time_t internally…"
[1] https://musl.libc.org/time64.html https://musl.libc.org/time64.html, "musl 1.2.0 changes the definition of time_t, and thereby the definitions of all derived types, to be 64-bit across all archs. … Individual users and distributions upgrading 32-bit systems to musl 1.2.x need to be aware of a number of ways things can break with the time64 transition, most of them outside the scope and control of musl itself."
[2] https://lwn.net/Articles/868221/ https://lwn.net/Articles/868221/, "XFS now supports filesystems containing dates after 2038. This support has been present for a while but is no longer considered experimental. "
[3] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign https://sourceware.org/glibc/wiki/Y2038ProofnessDesign, "In order to avoid duplicating APIs for 32-bit and 64-bit time, glibc will provide either one but not both for a given application; the application code will have to choose between 32-bit or 64-bit time support, and the same set of symbols (e.g. time_t or clock_gettime) will be provided in both cases."
[4] https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html https://www.gnu.org/software/libc/manual/html_node/Feature-T...
- pavon 4y agoA number of older file systems won't work past 2038, including ext3, reiser3 and xfs4[1]. You'll probably still be able to read them fine, just not write new files beyond that date, but it might be best to migrate any backups to a newer filesystem before then just in case, and certainly migrate any live systems that are still using them. [1] https://lwn.net/Articles/886708/ https://lwn.net/Articles/886708/
- tgv 4y agoThat's good advice when migrating. I'm sure 99% of the currently running servers and services will be migrated (or updated, upgraded) before 2038. Most don't store future timestamps, so there's 15 years to plan migration.
- pabs3 4y agoIIRC Debian plans to bootstrap new 32-bit-but-64-bit-time arches for some of the current 32-bit arches. Probably only armhf and i386 will get this treatment and possibly some of the unofficial arches like m68k. The other remaining 32-bit release arches (armel, mipsel) are likely to just get dropped. Cross-grading from the old arch names to the new ones will allow users to migrate old systems.
- Denvercoder9 4y agoGiven the state of armhf and i386 in Debian, I expect them to be dropped as release architectures before this plan will have materialized. As far as I'm aware there's barely anybody working on keeping them in okay-ish shape as-is, let alone rebootstrapping them with a 64-bit time_t.
- pabs3 4y agoWhat issues are you having with armhf and i386? They have about the same number of porters as any other arch (low single digits). Archive coverage is around the same or higher than other release arches. There are definitely people planning on rebootstrapping them, armhf more than i386 though, I've seen their work on IRC. https://release.debian.org/testing/arch_qualify.html https://release.debian.org/testing/arch_qualify.html
- mnw21cam 4y agoWon't that arch change mean that old binaries are incompatible? (I mean, I suppose that's half the point - if you want to verify that your system no longer has any software that suddenly breaks at a specific time, break it all now, but that strategy could also be really annoying.)
- pabs3 4y agoRight, thats the point, if you recompile a library with 64-bit-time, then it is ABI-incompatible with the 32-bit-time version of the library, so everything that uses the library would break unless you change the library ABI number and recompile everything that uses it. It would be possible to rename every single library that will be ABI-incompatible, but it would be a lot of work distributed across a lot of individual packages/maintainers and so a rebootstrap with a new system-wide ABI under a new arch name might be less work overall, especially when for many things just a recompile fixes it. There will still be a lot of stuff that needs patches though of course. Some threads about Y2038 from Debian folks: https://lists.debian.org/msgid-search/Y06EebE9aylMcSJk@alf.mars https://lists.debian.org/msgid-search/Y06EebE9aylMcSJk@alf.m... https://lists.debian.org/msgid-search/YzOs11RPkj30iFGj@atmark-techno.com https://lists.debian.org/msgid-search/YzOs11RPkj30iFGj@atmar... https://lists.debian.org/msgid-search/CAK8P3a0EtmgDRbDzBhOOZk_kyWmCm1aqvSxwUeY0R7tbCSxaKg@mail.gmail.com https://lists.debian.org/msgid-search/CAK8P3a0EtmgDRbDzBhOOZ... https://lists.debian.org/msgid-search/20200204131410.GF3043@tack.einval.com https://lists.debian.org/msgid-search/20200204131410.GF3043@... https://lists.debian.org/msgid-search/87pnm7dpe6.fsf@mid.deneb.enyo.de https://lists.debian.org/msgid-search/87pnm7dpe6.fsf@mid.den... https://lists.debian.org/msgid-search/20170901235854.ds4hffumd2ktggau@tack.einval.com https://lists.debian.org/msgid-search/20170901235854.ds4hffu... https://lists.debian.org/msgid-search/54B989EC.1070704@p10link.net https://lists.debian.org/msgid-search/54B989EC.1070704@p10li... https://lists.debian.org/msgid-search/CAC58tq_ZsjvTE6fgDWtw=QfHUwHzTAQ+bYimM4gEr7X+0pxDjw@mail.gmail.com https://lists.debian.org/msgid-search/CAC58tq_ZsjvTE6fgDWtw=... http://lists.debian.org/20100331022204.6338.63920.reportbug@skydancer.freeside.biz http://lists.debian.org/20100331022204.6338.63920.reportbug@...