Date: Sun, 6 Oct 2019 21:51:22 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> Cc: Cy Schubert <Cy.schubert@cschubert.com>, freebsd-arch@freebsd.org, Warner Losh <imp@bsdimp.com>, Shawn Webb <shawn.webb@hardenedbsd.org> Subject: Re: New CPUTYPE default for i386 port Message-ID: <20191006203059.H863@besplex.bde.org> In-Reply-To: <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org> References: <CANCZdfoFPsjyuCTfm0dQhz%2BsgVHLEvMA8-E3-Yhciz67qdoKvw@mail.gmail.com> <20191005173411.l6gs3kszs7zcgfey@mutt-hbsd> <CANCZdfo6=r7BaGA8qKYSR9ba=azzxD%2ByDkN4aO87Oj1Qr9TKmA@mail.gmail.com> <06E29438-732D-4045-8FB3-5F2A082E9B98@cschubert.com> <20f9896361c341736c5154c010cedf3fdcffc235.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Oct 2019, Ian Lepore wrote: > On Sat, 2019-10-05 at 14:20 -0700, Cy Schubert wrote: >> On October 5, 2019 11:19:41 AM PDT, Warner Losh <imp@bsdimp.com> >> wrote: >>> On Sat, Oct 5, 2019, 11:34 AM Shawn Webb < >>> shawn.webb@hardenedbsd.org> >>> wrote: >>> >>>> On Sat, Oct 05, 2019 at 09:28:53AM -0600, Warner Losh wrote: >>>>> > [...] >>>> I'm curious about the possibilities regarding 64-bit time_t on >>>> 32-bit >>>> Intel systems. A good source of bloat and bugs. >>> Beyond the scope of this discussion. However, feel free to start a >>> thread on this. It's quite difficult to switch if you want binary >>> compat. It would affect system calls on the upgrade path and is >>> among the hardest types to change if you have any kind of legacy to >>> support... >> >> This is one of the two reasons I believe we should deprecate 32-bit. >> Even supporting 32-bit compatibility long term is unsustainable. It >> is not worth the effort. >> >> Putting a stake in the ground to say we no longer support 32-bit >> after 2038 would be desirable. (Sooner the better though.) > > Only i386 has a 32-bit time_t. Other 32-bit arches either began life > with 64-bit time_t or have been switched to it. Linux compat has even more 32-bit types and even 16 bit types, for types that FreeBSE enlarged 26 years ago with 4.4BSD-Lite.. Better axe that too. Also COMPAT_FREEBSD*. > For i386, if its current users (and I am one, for $work) have a choice > between "As of date X there will be no more i386" and "As of date X we > switch time_t to 64 bits and you will not be able to run old binaries > after that" I suspect people would choose the latter. I would choose to actually use 32-bit (unsigned) time_t. This works unitl 2106. Unfortunately, it doesn't work before or soon after the Epoch (1970). POSIX doesn't require physical times before the Epoch to work, but FreeBSD userland (tzcode) supports such times, and even for POSIX small times that want to be negative occur after adding negative timezone offsets. Data structures are affected too. All ffs1 file systems (on all arches in FreeBSD) break in 2038 since file times are int32_t in ffs1. Delaying this breakage by changing to uint32_t is relatively trivial since there are no offsets and few instances of the error value -1 to worry about. Only support for times before the Epoch would be lost. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191006203059.H863>